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

[Patrick M Doane <patrick@watson.org>]

On Wed, 11 Jul 2001, Brian Rogoff wrote:

> On Wed, 11 Jul 2001, Krishnaswami, Neel wrote:
> > Sven [mailto:luther@dpt-info.u-strasbg.fr] wrote:
> > > On Tue, Jul 10, 2001 at 02:21:02PM -0400, Krishnaswami, Neel wrote:
> > > > 
> > > > Can you describe how I'd write something like the show function in 
> > > > Haskell, or the print-object generic function in Dylan? I've looked
> > > > at the G'Caml documentation, and it doesn't look like it's possible
> > > > to extend a generic function with new branches.
> > > 
> > > i think they are speacking about an extension to g'caml that 
> > > would use the include keyword and permit such extension.
> > > Please read the previous mails about this thread.
> > 
> > Ah, I misunderstood, then. I thought the claim was that include 
> > wouldn't be included, but that it wasn't necessary. 
> 
> No. The discussion is about whether the proposed include feature is
> sufficient. My original concerns had to do with modeling recursive
> generics in such a way that they can be extended (hence my question about
> a form of open recursion) and I think Patrick was proposing something 
> like dynamic binding (Patrick?). 

Not quite dynamic binding... I'd still like everything to be resolved
statically.  The thoughts I initially had were:

  1) Link time analysis once all types are known.  This isn't suitable
for all applications and is also much harder to implement, but still an
option.

  2) Specialized syntax to re-analyze the body of a derived generic to
avoid "cut and paste" polymorphism (I like that term Max!).  Eventually, I
realized this is present through the functor system.

To really make me happy, I'd like to be able to use functors and generics
without having any performance penalty for cases when it matters.  I know
this can lead to code bloat in general, but the C++ community is certainly
moving along just fine with it (and continuing to make improvements).
Maybe some options to the compiler to control this behavior would be
useful.

> I've managed to convince myself that once generics play with modules and
> functors, include will give me enough rope (to hang myself with :) for
> now. Still, it is different from type classes and CLOS/Dylan generics, so 
> read the papers, the mails by Jun Furuse on include, and start kicking
> those tires! 

It's definitely sufficient.  I think we'll still see a large number of
messages from people being confused by the lack of dynamic binding, but
that's okay -- the functor approach should be easier to understand/debug.

So here's another thought about G'caml.  Suppose we have two record types
like this:

type t1 = {
  t1_field: int
};

type t2 = {
  t2_field: int
};

The field names have to be unique to be able to access them, but we can
"share" the field name through a generic:

generic get_field = case
  | t1 -> int => fun x -> x.t1_field
  | t2 -> int => fun x -> x.t2_field

Any hope for a compiler to auto-generate these declarations and provide a
syntax similar to dot notation?

Patrick


-------------------
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