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

[bluestorm <bluestorm.dylc@gmail.com>]

>> > > 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.
>>
>> Yes for instance the very concise local opening notation comes in handy
>> here:
>>
>> if Int.(x = 42) then ... else ...
>
> That's very nice.  I don't think type classes are conservative enough for
> this project, but this comes very close indeed.
> I haven't really had a chance to explore OCaml 3.12 yet, as it came out
> while I was working on this, but I will give this serious consideration.

This approach is very nice indeed, but to make it practical you have
to have one of the two following features :
- a more restricted form of "open" statement that does not blindly
import *all* the module values
- nested modules

If you don't have any of these, you have to declare infix operators
directly inside the module. You'd have a "val (=) : int -> int ->
bool" in the "int.ml" file for example. That's notoriously painful to
handle if you use the "open" statement : a bunch of "open" statements
in a non-careful order and your infix operators become unusable
because you don't know anymore where they come from. What you really
need is some form of "explicit open", à la Python or Haskell, such as
"from Int import (mod, of_char, to_char)" instead of the full open :
only a few identifiers are unqualified, and you still use Int.(=),
Int.(+) instead of polluting the global namespace.

The other way to solve the problem is to put the dangerous infix
operators into a submodule, eg. Infix or Ops. You have a Int module
with int-specific functions that are not likely to silently conflict
with values of other modules, and an Int.Infix module meant to be used
in that "local open" form : Int.Infix(x + 1 = 2).