Re: "Re: [Caml-list] A G'Caml question" + additional info

[Brian Rogoff <bpr@best.com>]

On Sun, 1 Jul 2001, Patrick M Doane wrote:
> On Sat, 30 Jun 2001, Brian Rogoff wrote:
> > Less talk, more coding examples please.
> 
> Here's a simple example motivating my thoughts in this discussion:
> 
> generic get = case
>   | string -> int -> char => String.get
> 
> let print_first x = get x 0
> 
> generic get = case
>   | include get
>   | $a array -> int -> $a => Array.get
> ;;
> print_first [|0|]

Right, but I expect that if you want something like this you'll be
satisfied with adding the new print_first (re)definition after the new
get, or if you're just changing the program, at worst recompiling after
the change. If you have modules (GCaml doesn't yet), this should be fine.

The case that I see as annoying involves composing recursive generics, but
since in current versions of ML (Mosml 2 excepted) recursive definitions
don't span module boundaries this probably isn't too important. 

> As far as I can tell, there are no current plans for this kind of code
> to work with G'caml.

I don't find that troubling. You could still incrementally define "get". 

> > GCaml polymorphism is remarkably
> > easy to use. A while ago, when there was some discussion of overloading
> > on the list, Pierre Weis mentioned that he'd like a style of overloading
> > that would allow us to overload array access, string access, and hashtbl
> > access. How easy is that? Well, it writes itself from that sentence
> > 
> > generic get = case
> >   | string -> int -> char  => String.get
> >   | $a array -> int -> $a  => Array.get
> >   | $a list -> int -> $a => List.nth
> >   | ($a,$b) Hashtbl.t -> $a -> $b => Hashtbl.find 
> >   | ($a -> $b) -> $a -> $b => fun f -> f;;
> 
> This part works great - we get clear and powerful overloading. I really
> like it!
> 
> > This extensional polymorphism is beautiful, as well as practical. One of
> > the nice things about the STL is the way that it allows you to write the
> > algorithms independently of the containers, using the iterator interfaces. 
> > You can write functions over generics like "get" to achieve the same
> > effect in GCaml. 
> 
> The algorithms and containers can't be independent though because either:
> 
>   1) All containers (generic values) must be declared before any
> algorithms (derived generics) which use them are declared. 

I'm thinking about independence of source code. I don't believe I'd need 
to change the algorithm source which used get if I did a decent job of
modularization. 

>   2) Derived generics must include the generic values as parameters.
> 
> The first solution makes it difficult for users to extend a system.  If I
> redefine a generic value like get, then existing code cannot make use of
> it unless I 'cut and paste' to achieve genericity.

That's right. It's like regular function definitions, which don't have
open recursion. Mostly this is a good thing though, right? 

> > How doesn't it help?
> 
> The include feature, if I understand the proposition correctly, only
> applies to generic values and would not effect any derived generics that
> have been defined.  So I can't easily extend the definition of 'get' and
> have existing code make use of those improvements.  Here are some possible
> ideas: 
> 
>  1) Add a feature like 'include' which re-evaluates the definition of a
> derived generic in the current context.  This simplifies the 'cut and
> paste' approach by not specifying the code redundantly.
> 
>  2) Modify the semantics of derived generics such that the use of a
> generic value depends on a link-time (or run-time) analysis.  It was
> pointed out that this could be difficult to understand, but the OO system
> already has a similar confusion.
> 

>  3) Delegate this issue to the use of objects or functors.

I'm convinced that the include scheme, when properly integrated with
modules, will be sufficient. We need more experience with the current
scheme. 

> > While I think the STL is a fine design for a language like C++, I'm not
> > sure that STL emulation is high on my list of criteria for an OCaml 
> > overloading extension. 
> 
> Yes, the STL has little support for functional programming, and has other
> aspects which are messy.  Attempting to implement something close to STL
> in G'Caml is still a useful exercise though.  We can get a better sense
> for the differences between the two langauges.

I agree. 

> The point I wanted to make was that the object system can express many
> concepts of the C++ template system. I can't think of anything that
> wouldn't be expressible when G'caml is integrated with O'caml objects. 

C++ templates can express compile time computation; I don't think you can
do that in GCaml. I don't know if the STL makes use of that ability, or 
how well C++ compilers support it, etc. 

-- Brian


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr