The section 6.6 of OCaml's manual introduces a notion of "Parenthesized patterns".
I couldn't find any examples on how to use this feature, and brute-force approach doesn't work:
# match 1.0 with (y : float) -> print_float y | (s : string) -> print_string s;; This pattern matches values of type string but is here used to match values of type float #
On Monday 06 November 2006 21:15, Serge Aleynikov wrote:
> Could anyone point at a suitable resource?
I wasn't even aware that you could add type annotations inside a pattern. Your example will not work simply because OCaml's type system will not allow float to unify with string. You need some context where type inference will allow different possibilities, like a tuple containing both a float and a string:
# let f = function | (y : float), _ -> print_float y | _, (s : string) -> print_string s;;
or a polymorphic variant containing either a float or a string:
# let f = function | `F (y : float) -> print_float y | `S (s : string) -> print_string s;; val f : [< `F of float | `S of string ] -> unit = <fun>
> The section 6.6 of OCaml's manual introduces a notion of "Parenthesized > patterns".
> I couldn't find any examples on how to use this feature, and brute-force > approach doesn't work:
> # match 1.0 with > (y : float) -> print_float y > | (s : string) -> print_string s;; > This pattern matches values of type string > but is here used to match values of type float > #
> Could anyone point at a suitable resource?
What you wrote is equivalent to:
match ((1.0 : float) : string) with y -> print_float y | s -> print_string s
In OCaml, match-with is a test against the structure of a value, not its type. What you want to do is not currently possible in OCaml.
> Your > example will not work simply because OCaml's type system will not allow float > to unify with string. You need some context where type inference will allow > different possibilities, like a tuple containing both a float and a string:
> # let f = function > | (y : float), _ -> print_float y > | _, (s : string) -> print_string s;;
> or a polymorphic variant containing either a float or a string:
> # let f = function > | `F (y : float) -> print_float y > | `S (s : string) -> print_string s;; > val f : [< `F of float | `S of string ] -> unit = <fun>
Thanks. Several people also replied clarifying that the type annotations were merely used for aiding the type inferencer.
BTW, I think that G'Caml deserves more attention on this list (see http://lambda-the-ultimate.org/node/1278). (I've even thought that it is still a patch to OCaml 2.0, but it seems to be up-to-date now.)
You can check also a related attempt in Meta OCaml, by Oleg Kiselyov:
> The section 6.6 of OCaml's manual introduces a notion of "Parenthesized > patterns".
> I couldn't find any examples on how to use this feature, and brute-force > approach doesn't work:
> # match 1.0 with > (y : float) -> print_float y > | (s : string) -> print_string s;; > This pattern matches values of type string > but is here used to match values of type float > #
> BTW, I think that G'Caml deserves more attention on this list (see > http://lambda-the-ultimate.org/node/1278). (I've even thought that it > is still a patch to OCaml 2.0, but it seems to be up-to-date now.)
The GCaml docs say (and have said for at least a year) that it doesn't support all of OCaml, neither objects nor polymorphic variants. I'd guess that it doesn't support recursive modules either.
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.
> BTW, I think that G'Caml deserves more attention on this list (see > http://lambda-the-ultimate.org/node/1278). (I've even thought that it > is still a patch to OCaml 2.0, but it seems to be up-to-date now.)
I am certainly interested in GCaml but:
Where do you get it from (the CVS doesn't seem to have it)? How fast is it? Does it support native code? What version of OCaml is it based upon?
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
On Thu, 9 Nov 2006, skaller wrote: > 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 just did a quick scan of some F# docs and I saw nothing. What did you have in mind?
> > I'm not convinced that it is a good idea yet...
For almost any given language feature, there will be people who like it, and people who don't. Do you think having class based OO in OCaml is a good idea? I find it useful, especially since OCaml records are far too restrictive, but I hope that in some future ML that there are other approaches as the class/object system is complex, and the interactions with "core ML + modules" is tricky.
That said, the class system is being used and it won't go away, and some people really like it.
> 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.
On Thu, 2006-11-09 at 08:22 -0800, brogoff wrote: > On Thu, 9 Nov 2006, skaller wrote: [] > > So it now has first order typeclasses to solve this problem.
> Did you consider GCaml style generic functions?
Yes, but they seem a bit harder to implement. The closure is nice though. The example has a type like:
{ 'a -> 'a -> 'a < [| int -> int -> int | float -> float -> float |] }
but I don't know how to unify alternatives.
Feels a bit like a GLR parser .. you fork the unification with each case, drop a thread when unification fails, and merge successes into alternatives?
-- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net
