Thanks a lot for the answers.

Another feature I really miss is type parameterized modules.

For example, suppose I have a module that defines simple geometry / linear algebra math, with types like Vector a, Matrix a, Point a, Size a, Rectangle a, etc...

Usually when you import such a module, you will be picking one particular type for "a" across the whole module or even program, e.g. Double, Float, Complex Double. 

I see such a type more like a "module global type", so instead of writing

import qualified MyGeometry (Vector, Matrix, Point, Size, Rectangle) as G

type Vector = G.Vector Float
type Matrix = G.Matrix Float
type Point = G.Point Float

etc

I would like to write

import (MyGeometry Float)

or even

module (MyGame real)

import (MyGeometry real)

and then I can just use Vector, Matrix, etc, without specifying the type. So it's as if (MyGeometry Float) performs a "partial type application", just like ((+) 1) does "partial value application"

However, when writing

import MyGeometry 

one would have to use the parametrized version of Vector etc again.

I'm not sure if this makes any sense, or if it is even worth considering :-)


On Sat, Sep 26, 2009 at 6:30 AM, Sebastian Sylvan <sebastian.sylvan@gmail.com> wrote:


On Fri, Sep 25, 2009 at 10:55 PM, Casey Hawthorne <caseyh@istar.ca> wrote:
On Fri, 25 Sep 2009 23:25:21 +0200, you wrote:

>On Fri, Sep 25, 2009 at 8:14 PM, Job Vranish <jvranish@gmail.com> wrote:
>
>> Supposedly OCaml has an OO feature that does this but I haven't tried it
>> out.
>>
>
>Indeed, OCaml has stuctural polymorphism, it's a wonderful feature.
>
>*# let f myobj = myobj#foo "Hi !";;
>val f : < foo : string -> 'a; .. > -> 'a = <fun>*
>
>IIRC, there has been work on Template Haskell for structural polymorphism.

Structural subtyping/polymorphism:

Pros:
- an object can be coerced to any compatible type, the types do not
have to be specified ahead of time, that is at compile time.

Cons:
- may be overly permissive; some coercions might not make sense
semantically.

I wonder how Haskell will minimize the cons, since it is strongly
typed.


I kind of think there's no real problem here. If you say that you can accept any record with a given set of fields, then you have to make sure you make no other assumptions. This is, in principle, no different from passing a speed Double to a function that expects a mass Double (e.g. it may produce garbage for negative values). In both cases a function that requires extra invariants can enforce it by using a newtype that's constructed and manipulated in a way which preserves the extra semantic rules.

--
Sebastian Sylvan

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