Re: [Caml-list] interest in a much simpler, but modern, Caml?

[Nicolas Pouillard <nicolas.pouillard@gmail.com>]

On Sun, 8 Aug 2010 15:39:28 -0400, Jeremy Bem <jeremy1@gmail.com> wrote:
> On Sun, Aug 8, 2010 at 2:52 PM, Florian Weimer <fw@deneb.enyo.de> wrote:
> 
> > * Jeremy Bem:
> >
> > > Yes and no, respectively.  In other words, nothing new here.
> >
> > Oh.  I just happen to think that those two are very high on the list
> > of things you want to fix once you can start with a clean slate.
> >
> > > Is there a better approach to polymorphic equality floating around?
> >
> > Besides type classes?  I'm not sure.  It's probably possible to remove
> > this feature from the language, with a little bit of syntactic
> > overhead to pass around a matching comparison function.
> >
> 
> Maybe I should clarify that my main goal has been to bring Caml Light
> up-to-date with OCaml's improvements, while keeping the type-checking code
> very simple, not to try to make further improvements.  In fact, I wouldn't
> necessarily claim that omitting the module and object systems is an
> improvement, just that it is a simplification.
> 
> But actually, now that you mention it, I did briefly explore the idea of
> removing Caml's polymorphic comparison functions.
> 
> One issue I ran into was syntactic.  How would you write:
>   if 'A' <= c && c <= 'Z' then ...
> where c is a char, without polymorphic comparison, and without more radical
> changes such as type classes?  Ideally the solution would generalize to
> int64s, etc.

As said in my previous email local opening can help here:

if Char.('A' <= c && c <= 'Z') then ...

> I also found multiple instances of a pattern like
>   type foo = Foo of int | Goo of string
>   if myfoo = Foo 3 then ...
> It felt tedious and perhaps destructive to re-code all of these.

Having to recode them sure is tedious but very simple as well in these
case:

match myfoo with Foo 3 -> ... | ...

> Finally, on what theoretical basis do we disallow polymorphic comparison but
> retain polymorphic hashing and marshalling? Perhaps we just want all these
> functions to be less convenient, e.g. isolated in their own "Polymorphic"
> module.  After all, Llama retains even the "Obj" module.

With type clases you would have a class for each of them. For sure it make
sense to keep them all like you keep the Obj module the difference is the
intended usage if they are called Unsafe_generic_equality.(=),
unsafe_generic_hash, and unsafe_generic_marshalling then its fine. For sure
we then want to expose safer variants of those to the user.

Another idea that can help would be to have only one builtin type class
(no not the equality one as in SML), the Typeable class. This class simply
expose a value to represent a type. In these three cases (equality, marshalling,
and hashing) we will even don't look at these values, the purpose is
to give us the right to behave in a non-parametric way. However it does not
fix the equality for abstract types, so I don't know if the gain worth the
added complexity.

> If there is a broad consensus for immutable strings, I could make that
> change as well, again with a bit of delay as I'll need to port things like
> the relocation mechanism in the Llama linker, in order to remain
> self-hosting.

For sure it would a lot nicer to have at least a type for immutable strings
and make the literals immutable. Then having a second type for mutable strings
and two copying functions (freeze and thaw) to convert them would help you
a lot in adapting existing code.

Regards,

-- 
Nicolas Pouillard
http://nicolaspouillard.fr