Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] C++ STL and template features compared with OCaml parametric polymorphism and OO features
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: brogoff <brogoff@s...>
Subject: Re: [Caml-list] Factoring HOFs
On Fri, 1 Oct 2004, Jacques Garrigue wrote:
> From: Keith Wansbrough <Keith.Wansbrough@cl.cam.ac.uk>
> >
> > but OCaml doesn't allow nested quantifiers (i.e., higher-rank
> > polymorphism).
> >
> > It actually wouldn't be very hard to support, if you're prepared to
> > accept the need for the occasional type annotation - see
> > http://research.microsoft.com/~simonpj/papers/putting/index.htm.
>
> OCaml has been supporting nested quantifiers for years.
> However, they are a little more verbose because we chose to allow
> unpredicate 2nd order types, which are harder to infer.
>
> Look in the manual for polymorphic record fields and polymorphic
> methods. The former are lighter syntactically, but require an
> explicit record definition in advance, while the latter allow defining
> polymorphic values on the fly.

These are good additions to the language which allow you to do lots of things,
like encode Okasaki's algorithms more directly, but they don't seem like a
satisfactory solution. It would be better to just have the user give a type
annotation on functions I think. Also for recursive types, it seems like it
would better to allow them in the language with explicit annotations rather than
having a compiler switch or having to wrap in constructors.

> But your example also uses constructor variables, which are not
> available in ocaml. Note however that you can still encode it using
> a functor:

Nice.  Xavier Leroy used a similar encoding a while back to simulate
higher order type constructors. This trick seems FAQworthy.

It's funny, because I read some paper by Haskell guys talking about how
the ML module system is powerful but overcomplex (hope I'm not misstating the
intent of the paper!) yet it seems more intuitive than type classes to me.

-- Brian

> module Map2(M : sig type 'a f val map : ('a -> 'b) -> 'a f -> 'b f end) =
>   struct
>     let map2 g f x = M.map g (M.map f x)
>   end
>
> Not much longer, he?
> You can apply this functor locally with "let module".
>
> let to_string l =
>   let module M = Map2(struct type 'a f = 'a list let map = List.map end) in
>   M.map2 string_of_int (fun x -> x + 1) l
>
> Jacques
>
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners