Browse thread
parameterized pattern
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | skaller <skaller@u...> |
| Subject: | Re: [Caml-list] parameterized pattern |
On Thu, 2006-11-09 at 05:19 +0000, Jon Harrop wrote:
> On Thursday 09 November 2006 01:45, brogoff wrote:
> > It's a pity, as I've often wished that OCaml supported the extensional
> > polymorphism that GCaml has, but I don't think that's going to happen.
> > It would probaby make more sense to create a separate language at this
> > point, since OCaml is complicated enough.
>
> I think F# provides some form of extensional polymorphism. I'm not convinced
> that it is a good idea yet...
Well FYI Felix has traditional (open) overloading, but since it
doesn't allow traditional C++ style dependent name lookup because
that would destroy parametricity of polymorphic functions,
something else was needed.
So it now has first order typeclasses to solve this problem.
[By first order I mean typeclass arguments can be types but
not type constructors, i.e. it only supports data polymorphism,
not functorial polymorphism/polyadic programming]
This allows you to write stuff like this:
typeclass Integer[t] {
virtual fun add: t * t -> t;
}
fun sum3[t where Integer[t]] (x:t,y:t,z:t)=> add(x,add(y,z));
print (sum3(1,2,3));
instance Integer[int] {
fun add: int * int -> int = "$1+$2"; // C code
}
open Integer[int];
print (add(add(1,2),3));
I'm not sure i really like typeclasses much, ML functors
seem more general, and the coupling is explicit.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net