On Oct 19, 2007, at 12:11 , Sebastian Sylvan wrote:

On 19/10/2007, Kalman Noel wrote:

...

data ExistsNumber = forall a. Num a => Number a

I'm without a Haskell compiler, but shouldn't that be "exists a."?

The problem is that "exists" is not valid in either Haskell 98 or any current extension, whereas "forall" is a very common extension. But you can simulate "exists" via "forall", which is the thrust of these approaches. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Peter Hercek wrote:

When 'exists' is not a keyword, why 'forall' is needed at all? Isn't everything 'forall' qualified by default?

“forall” isn't a keyword in Haskell 98. As an extension to the language, however, it makes certain types expressible that can not be written in H98, for example f :: (forall a. a) -> T which is different from g :: forall a. a -> T although both are not particularly useful. (The only argument that f will ever take is bottom!) In the context of existentially quantified types, however, the forall keyword is used probably to make the use of an extension more explicit. Without the forall keyword, data U = C a would be an existential, while the programmer maybe really wanted the usual data U a = C a Kalman ---------------------------------------------------------------------- Find out how you can get spam free email. http://www.bluebottle.com/tag/3

Sebastian Sylvan wrote:

On 19/10/2007, Kalman Noel wrote:

...

data ExistsNumber = forall a. Num a => Number a

I'm without a Haskell compiler, but shouldn't that be "exists a."? IIRC forall will work too, but the "right" way to do it is "exists", right?

No. It's been suggested but that's not how GHC or Hugs existentials work. The syntax isn't actually illogical, it's just very confusing. What (by convention) you are actually doing here is you are annotating the type of the constructor. So you are saying that the constructor 'Number' has the type "forall a . Num a => a -> ExistsNumber". This is perfectly correct, but it is confusing that what you are doing is annotating the *constructor* and not the data-type itself, per se, although it doesn't much look like it. This looks very very much clearer in GADT syntax, since in GADT syntax you always give constructors explicit types: type ExistsNumber where Number :: forall a . Num a => ExistsNumber a Jules

If I understand what you're going for with the code below, then here's another way to program it in SML that doesn't use exceptions (the control flow mechanism) at all. I think what you want is an extensible datatype. Here's the interface I program to: signature TAGGED = sig (* a tag is the equivalent of a datatype constructor for our extensible datatype *) type 'a tag val newtag : unit -> 'a tag (* the extensible datatype itself: - the datatype is statically extensible (you can add new constructors in different parts of the program text) - the datatype is dynamically extensible (you can add new constructors at runtime) *) type tagged (* tag a value (i.e., the equivalent of a datatype constructor application) *) val tag : 'a tag -> 'a -> tagged (* match with a given tag (i.e., the equivalent of pattern matching) *) val istagof : 'a tag -> tagged -> 'a option end A simple use is as follows: structure Use = struct open Tagged val i : int tag = newtag () val s : string tag = newtag () val l : tagged list = [tag i 1, tag s "hi"] fun toString (t : tagged) = case istagof i t of SOME (x : int) => Int.toString x | NONE => case istagof s t of SOME (x : string) => x | NONE => raise Fail "don't know about that tag" end Of course, we could have written this particular code with a datatype. But you could also add new tags elsewhere in the program, or even generate them in a loop at runtime. So for your example below, the point stuff would look like: type point = int * int val p : point tag = newtag () fun extractPoint (t : tagged) : point = case istagof p t of SOME p => p | NONE => (0,0) (* whatever default value you want *) And then you'd write render : tagged -> RenderedImage (Now, you may want render to be an extensible function, so you can add cases elsewhere in the program, but that's a story for another time.) Now, the implementation of TAGGED uses the SML exn type, which, despite the concrete syntax, has absolutely nothing to do with exceptions. It's much better to think of exn as standing for EXteNsible: it's just an extensible datatype; the choice of keyword "exception" for adding a new datatype constructor is misleading. In fact, TAGGED is just a nicer interface on top of exn: structure Tagged :> TAGGED = struct type 'a tag = ('a -> exn) * (exn -> 'a option) type tagged = exn fun newtag () = let exception E of 'a in (E, fn (E x) => SOME x | _ => NONE) end fun tag (f, _) x = f x fun istagof (_, g) x = g x end -Dan On Oct20, TJ wrote:

Dan Licata: Thanks for explaining the mechanics behind it. Knowing how it (could) be implemented always helps me understand things.

On 10/20/07, Jules Bean wrote:

...

Quite often an explicit ADT is much nicer. But they represent two opposing patterns of code-writing. Explicit ADT allows you to write case statements handling 'all the logic in one place'; a class forces you to separate the differences into 'separate instances'.

Nice ADT example. Indeed that would be how I'd do it in SML. Use a record type holding closures referencing an object of unknown type. The nice thing I've found about doing it in SML this way is that I can extract the object back out, using exceptions. e.g.

(* Start Standard ML *)

datatype Renderable = Renderable { render : unit -> RenderedImage, extract : unit -> unit, tag : exn }

local datatype Point = Point Something exception ExtractMe Point exception Tag in fun mkPoint Something = let val p = Point Something in { render = fn () => ... , extract = fn () => raise ExtractMe p, tag = Tag } end (* extractPoint would return the Point hidden away in a Renderable. *) fun extractPoint (Renderable { tag = Tag, extract, ... }) = (extract (); Point SomethingPointless) handle ExtractMe p => p end

(* End SML *)

I don't know if this would work in Haskell, as I'm not familiar with Haskell exceptions. Anyway I see that Haskell has a Dynamic type...

I've got a good grip on this now, I think. Thanks everyone.

TJ _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 10/22/07, Tim Docker wrote:

TJ:

...

After all, sometimes all you need to know about a list is that all the elements support a common set of operations. If I'm implementing a 3d renderer for example, I'd like to have

class Renderable a where render :: a -> RasterImage

scene :: Renderable a => [a]

Everyone has launched into explanations of how to use existentials to do this, but you may be happy in just haskell 98. In the above, you could just have:

scene :: [RasterImage]

Laziness will ensure that the computation/storage of the images will not occur until they are used.

Tim

Ah... indeed it can, in this case. It won't work if class Renderable also has a method for saving to file, etc, I suppose, unless scene :: [(RasterImage,IO (),...whatever other operations...)] Thanks for the heads up :) TJ

On 10/22/07, Tim Docker wrote:

[...] You may then like to add a type class to turn things into renderables:

class IsRenderable where toRenderable :: a -> Renderable

instance IsRendeable Point where ... instance IsRenderable Line where ... [...]

Cool. I should get more familiar with basic Haskell98 before I decide on using GHC extensions... Thanks, TJ