Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Jeremy Bem <jeremy1@gmail.com>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: caml-list List <caml-list@yquem.inria.fr>
Subject: Re: [Caml-list] interest in a much simpler, but modern, Caml?
Date: Sun, 8 Aug 2010 15:39:28 -0400	[thread overview]
Message-ID: <AANLkTinP=6cJngRum-oxeNJ01yCnUyTD4CQ9FNd8Z1tY@mail.gmail.com> (raw)
In-Reply-To: <87bp9dkkca.fsf@mid.deneb.enyo.de>

[-- Attachment #1: Type: text/plain, Size: 2620 bytes --]

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.

I briefly had lexer support for a syntax along the lines of
  if 'A' <=`c` c && c <=`c` 'Z' then ...
In general, the backquote is available since I don't support variants.
 However, this syntax didn't feel elegant enough to warrant expanding the
Llama project's more conservative scope.  Currently OCaml can compile Llama
code, a feature which doesn't seem like it should be discarded too lightly.

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.

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.

Once the current system is posted, I could consider making these changes
after all.  Suggestions to smooth the syntax are more than welcome.  Perhaps
a bit more time to re-code things carefully is all that is really needed.

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.

Thanks,
Jeremy

[-- Attachment #2: Type: text/html, Size: 3383 bytes --]

  reply	other threads:[~2010-08-08 19:39 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-06  4:04 Jeremy Bem
2010-08-06 13:50 ` [Caml-list] " Eray Ozkural
2010-08-08 17:59 ` Florian Weimer
2010-08-08 18:44   ` Jeremy Bem
2010-08-08 18:52     ` Florian Weimer
2010-08-08 19:39       ` Jeremy Bem [this message]
2010-08-09 11:55         ` Nicolas Pouillard
2010-08-11 13:00         ` Jon Harrop
2010-08-08 20:53       ` Nicolas Pouillard
2010-08-08 20:59         ` Jeremy Bem
2010-08-08 21:47           ` bluestorm
2010-08-08 23:00             ` Christophe TROESTLER
2010-08-08 23:29             ` Jeremy Bem
2010-08-11 13:02               ` Jon Harrop
2010-08-12  0:21                 ` Jeremy Bem
2010-08-12 23:14                   ` Jon Harrop
2010-08-09 13:10             ` David House
2010-08-09 14:03               ` Nicolas Pouillard
2010-08-08 20:52     ` Nicolas Pouillard
2010-08-11 12:56     ` Jon Harrop
2010-08-09  6:37 ivan chollet
2010-08-09 10:54 ` Cedric Cellier
2010-08-09 15:00 ` ivan chollet
2010-08-09 15:03 ` ivan chollet
2010-08-11 13:19 ` Jon Harrop
2010-08-11 16:12   ` philippe
2010-08-12  6:56   ` ivan chollet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='AANLkTinP=6cJngRum-oxeNJ01yCnUyTD4CQ9FNd8Z1tY@mail.gmail.com' \
    --to=jeremy1@gmail.com \
    --cc=caml-list@yquem.inria.fr \
    --cc=fw@deneb.enyo.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox