English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
interest in a much simpler, but modern, Caml?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-08-08 (23:29)
From: Jeremy Bem <jeremy1@g...>
Subject: Re: [Caml-list] interest in a much simpler, but modern, Caml?
On Sun, Aug 8, 2010 at 5:47 PM, bluestorm <bluestorm.dylc@gmail.com> wrote:

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

I don't believe there is really any issue here.  Certain modules are simply
not intended to opened to be opened globally.  This is already the case:
witness the many standard library modules that define "length", "map",
"iter", etc.