On Fri, 29 Jun 2001, John Max Skaller wrote:

> Patrick M Doane wrote:
> 
> > >   We do not want to introduce the full open recursion to generic
> > > values. You could add new type cases easily using the open recursion
> > > and it should be helpful in some cases. But it can also introduce
> > > heavy semantic confusion to our programs, since in the open recursion
> > > the semantics of generic values could not be fixed until all modules
> > > are linked together.
> > 
> > I agree that this could make programs more difficult to follow, but I
> > think it is to be expected with generic programming these days.
> 
> 	Yes, its expected: which is very good reason NOT to do it.
> Its expected that all the problems associated with it have to exist,
> because people haven't seen anything better.

I would like to apply the generic programming techniques so that I can
have reusable algorithms.  The extensions provided by GCaml don't achieve
that goal although they are much more powerful than basic operator
overloading. 

If I want to define a generic function similar to the STL for_each
function, this works fine until I need to extend the system with new
iterator types.  The proposed 'include' feature makes it much easier to
extend generic values, but doesn't help with derived generics. I would
assume that most folks are interested in the reusability of those derived
generics.  Does it make sense to provide a similar construct to 'include'
for derived generics which would re-analyze the body of the code based on
a new context of generic values?  Or am I trying to abuse what these
features are intended for? Maybe this kind of approach is better suited to
the object system or using functors.

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