interest in a much simpler, but modern, Caml?

interest in a much simpler, but modern, Caml?

[Jeremy Bem]

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

Dear caml-list,

To support my research, I've developed an implementation ("Llama Light") of
the core Caml language. Modules, objects, labels etc are not supported
(except for file-level modules). The system strongly resembles OCaml,
however the completely rewritten typechecker is not only much smaller in
terms of lines-of-code; it has a genuinely simpler design owing especially
to the lack of first-class modules.  This wasn't obtained by stripping down
OCaml, but rather by integrating OCaml features into Caml Light (although
this history isn't visible in the end result).  In a strict type-theoretic
sense, the system is even simpler than Caml Light; I'll postpone the
details.

The system is fully self-hosting; all the main tools have been ported to the
smaller language, e.g. "llamadoc" replaces ocamldoc, etc. The standard
library has been ported as well, such as non-functorial versions of the Map
and Set modules.  Only the native-code compiler is missing, and that doesn't
look like more than a day's work or so.

My plans now call for adding features to replace the ones I've removed,
namely experimental ones related to assisted theorem proving and inductive
programming. However, it occurs to me that others might find the
stripped-down "base system" to be useful for their own experiments.
 Obtaining it was a non-trivial amount of work, and I've tried to write the
code clearly and carefully.  So -- this posting is intended as a gauge of
interest.  How much effort should I expend to package what I've got, before
adding my own experimental features?  With community support (and a good
approach to the Q License), maybe I could manage something fairly polished.

Thanks,
Jeremy

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

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

[Eray Ozkural]

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

On Fri, Aug 6, 2010 at 7:04 AM, Jeremy Bem <jeremy1@gmail.com> wrote:
>
> My plans now call for adding features to replace the ones I've removed,
> namely experimental ones related to assisted theorem proving and inductive
> programming.
>

Dear Jeremy,

What have you got on inductive programming?

Best,

--
Eray

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

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

[Florian Weimer]

* Jeremy Bem:

> To support my research, I've developed an implementation ("Llama Light") of
> the core Caml language. Modules, objects, labels etc are not supported
> (except for file-level modules). The system strongly resembles OCaml,
> however the completely rewritten typechecker is not only much smaller in
> terms of lines-of-code; it has a genuinely simpler design owing especially
> to the lack of first-class modules.

How do you deal with strings (are they mutable?) and polymorphic
equality (is it type-safe?)?

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

[Jeremy Bem]

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

On Sun, Aug 8, 2010 at 1:59 PM, Florian Weimer <fw@deneb.enyo.de> wrote:

> * Jeremy Bem:
>
> > To support my research, I've developed an implementation ("Llama Light")
> of
> > the core Caml language. Modules, objects, labels etc are not supported
> > (except for file-level modules). The system strongly resembles OCaml,
> > however the completely rewritten typechecker is not only much smaller in
> > terms of lines-of-code; it has a genuinely simpler design owing
> especially
> > to the lack of first-class modules.
>
> How do you deal with strings (are they mutable?) and polymorphic
> equality (is it type-safe?)?
>

Yes and no, respectively.  In other words, nothing new here.

Strings can be made immutable (in both Llama and OCaml) by disabling
String.set in the standard library (the s.[i] <- c construct is just sugar
for a call to that function).

Is there a better approach to polymorphic equality floating around?

-Jeremy

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

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

[Florian Weimer]

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

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

[Jeremy Bem]

[-- 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 --]

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

[Nicolas Pouillard]

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

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

[Jon Harrop]

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

SML's ad-hoc polymorphism. Would also be nice if you could fill out the
primitive types with 32-bit floats, ints of different sizes and so on.

Also, would be excellent if you could make the compiler agnostic with regard
to the run-time representation of these types so a new back-end could unbox
all primitive types.

Cheers,
Jon.

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

[Nicolas Pouillard]

On Sun, 08 Aug 2010 20:52:53 +0200, 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.

Yes for instance the very concise local opening notation comes in handy here:

if Int.(x = 42) then ... else ...

-- 
Nicolas Pouillard
http://nicolaspouillard.fr

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

[Jeremy Bem]

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

On Sun, Aug 8, 2010 at 4:53 PM, Nicolas Pouillard <
nicolas.pouillard@gmail.com> wrote:

> On Sun, 08 Aug 2010 20:52:53 +0200, 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.
>
> 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.

-Jeremy

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

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

[bluestorm]

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

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

[Christophe TROESTLER]

On Sun, 8 Aug 2010 23:47:20 +0200, bluestorm 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

This is possible to do with Delimited Overloading (pa_do):
http://pa-do.forge.ocamlcore.org/

> - nested modules
> 
> 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).

This is possible to "import" the overloaded functions form a submodule
but has to be done by hand for the moment because there is no
consensus on what the name of the submodule should be.

My 0.02€,
C.

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

[Jeremy Bem]

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

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.

-Jeremy

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

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

[Jon Harrop]

> > if Int.(x = 42) then ... else ...

> This approach is very nice indeed

What happens when you do:

  if Int.(x = 42 || x = 45) then ... else ...

Presumably it either barfs on the assumption that "||" refers to bitwise-or
between ints, or we're back to inventing progressively more absurd operator
names for each individual combination of types over which they might work.

Cheers,
Jon.

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

[Jeremy Bem]

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

On Wed, Aug 11, 2010 at 9:02 AM, Jon Harrop <
jonathandeanharrop@googlemail.com> wrote:

>
> What happens when you do:
>
>  if Int.(x = 42 || x = 45) then ... else ...
>
> Presumably it either barfs on the assumption that "||" refers to bitwise-or
> between ints, or we're back to inventing progressively more absurd operator
> names for each individual combination of types over which they might work.
>

How so?  I think this is a borderline case (even in C++, "||" does not refer
to bitwise-or).  But even if Int.(||) *were* defined as some sort of integer
operation, one could simply write:
  if Int.(x = 42) || Int.(x = 45)

Also, I think the discussion has shifted.  For me, the local open is a
reasonably appealing way to stop using OCaml's exotic polymorphic operators
whose behavior depends on the runtime representation and which don't respect
type abstraction.  (For example, ocamllex uses Pervasives.(=) to test
whether Map's are empty, but this breaks if the Map representation changes.)
 Moreover the syntax even maintains OCaml compatibility thanks to the recent
update.  But now we seem to be talking about operator overloading, and I'm
just not convinced it's necessary at all in a system with a minimalist
aesthetic.

Back to the local opens, I find that I'm hesitant to add so many of them,
especially for equality.  Polymorphic equality is hardly unnatural, after
all (cf. higher-order logic).  I wonder, do any practical languages use
quotient types to implement custom equality predicates?  In principle,
Pervasives.(=) ought to be the "finest" reasonable equivalence relation on a
type, which could then be coarsened:

type foo = Foo of int | Goo of string
let _ = assert (Foo 3 <> Goo "3") (* duh *)
let foo_equiv x y =
  match x, y with
    Foo a, Foo b -> a=b
  | Goo a, Goo b -> a=b
  | Foo a, Goo b
  | Goo b, Foo a -> string_of_int a = b
type goo = foo / foo_equiv (* automatically creates goo_of_foo *)
let _ = assert (goo_of_foo (Foo 3) = goo_of_foo (Goo "3"))

This would require runtime support.  I envision that every "goo" is a block
whose tag is "Quotient_tag" and which stores a "foo_equiv" closure in its
first Obj field.

As it happens, this approach would dovetail with my plans for an integrated
proof assistant.  Of course it lacks the "conservatism" I've been promoting
:)

-Jeremy

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

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

[Jon Harrop]

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

Presumably, in general, that would need to be:

 

  If Bool.(Int.(x=42) || Int.(x=45)) .

 

At which point things start to look hairy. To be honest, I see this
delimited overloading as the best of a bad job in the absence of equality
types or per-type functionality. I think what we really want is to be able
to define custom equality, comparison and hashing on types when structural
versions are not applicable. F#'s solution is pretty good. Type classes are
a generalization but I do not see that they buy you much for the added
complexity.

 

I'd have thought this (at least equality types) would be worth putting in a
minimalistic language because it is so useful.

 

Cheers,

Jon.

 

From: Jeremy Bem [mailto:jeremy1@gmail.com] 
Sent: 12 August 2010 01:22
To: Jon Harrop
Cc: bluestorm; caml-list List; Florian Weimer
Subject: Re: [Caml-list] interest in a much simpler, but modern, Caml?

 

On Wed, Aug 11, 2010 at 9:02 AM, Jon Harrop
<jonathandeanharrop@googlemail.com> wrote:

 

What happens when you do:

 if Int.(x = 42 || x = 45) then ... else ...

Presumably it either barfs on the assumption that "||" refers to bitwise-or
between ints, or we're back to inventing progressively more absurd operator
names for each individual combination of types over which they might work.

 

How so?  I think this is a borderline case (even in C++, "||" does not refer
to bitwise-or).  But even if Int.(||) *were* defined as some sort of integer
operation, one could simply write:

  if Int.(x = 42) || Int.(x = 45)

 

Also, I think the discussion has shifted.  For me, the local open is a
reasonably appealing way to stop using OCaml's exotic polymorphic operators
whose behavior depends on the runtime representation and which don't respect
type abstraction.  (For example, ocamllex uses Pervasives.(=) to test
whether Map's are empty, but this breaks if the Map representation changes.)
Moreover the syntax even maintains OCaml compatibility thanks to the recent
update.  But now we seem to be talking about operator overloading, and I'm
just not convinced it's necessary at all in a system with a minimalist
aesthetic.

 

Back to the local opens, I find that I'm hesitant to add so many of them,
especially for equality.  Polymorphic equality is hardly unnatural, after
all (cf. higher-order logic).  I wonder, do any practical languages use
quotient types to implement custom equality predicates?  In principle,
Pervasives.(=) ought to be the "finest" reasonable equivalence relation on a
type, which could then be coarsened:

 

type foo = Foo of int | Goo of string

let _ = assert (Foo 3 <> Goo "3") (* duh *)

let foo_equiv x y =

  match x, y with

    Foo a, Foo b -> a=b

  | Goo a, Goo b -> a=b

  | Foo a, Goo b

  | Goo b, Foo a -> string_of_int a = b

type goo = foo / foo_equiv (* automatically creates goo_of_foo *)

let _ = assert (goo_of_foo (Foo 3) = goo_of_foo (Goo "3"))

 

This would require runtime support.  I envision that every "goo" is a block
whose tag is "Quotient_tag" and which stores a "foo_equiv" closure in its
first Obj field.

 

As it happens, this approach would dovetail with my plans for an integrated
proof assistant.  Of course it lacks the "conservatism" I've been promoting
:)

 

-Jeremy

 


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

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

[David House]

On 8 August 2010 17:47, bluestorm <bluestorm.dylc@gmail.com> wrote:
> 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.

If you're willing to explicitly name the things you wish to import
then this doesn't seem to be a hard problem to solve:

let mod = Int.mod
let of_char = Int.of_char
let to_char = Int.tochar

Or even, in 3.12,

let mod, of_char, to_char = Int.(mod, of_char, to_char)

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

[Nicolas Pouillard]

On Mon, 9 Aug 2010 09:10:43 -0400, David House <dmhouse@gmail.com> wrote:
> On 8 August 2010 17:47, bluestorm <bluestorm.dylc@gmail.com> wrote:
> > 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.
> 
> If you're willing to explicitly name the things you wish to import
> then this doesn't seem to be a hard problem to solve:
> 
> let mod = Int.mod
> let of_char = Int.of_char
> let to_char = Int.tochar

You may want to import types, data constructors, exceptions, modules as
well... While some of them can be mitigated data constructors cannot AFAIK.

-- 
Nicolas Pouillard
http://nicolaspouillard.fr

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

[Nicolas Pouillard]

On Sun, 8 Aug 2010 14:44:11 -0400, Jeremy Bem <jeremy1@gmail.com> wrote:
> On Sun, Aug 8, 2010 at 1:59 PM, Florian Weimer <fw@deneb.enyo.de> wrote:
> 
> > * Jeremy Bem:
> >
> > > To support my research, I've developed an implementation ("Llama Light")
> > of
> > > the core Caml language. Modules, objects, labels etc are not supported
> > > (except for file-level modules). The system strongly resembles OCaml,
> > > however the completely rewritten typechecker is not only much smaller in
> > > terms of lines-of-code; it has a genuinely simpler design owing
> > especially
> > > to the lack of first-class modules.
> >
> > How do you deal with strings (are they mutable?) and polymorphic
> > equality (is it type-safe?)?
> >
> 
> Yes and no, respectively.  In other words, nothing new here.
> 
> Strings can be made immutable (in both Llama and OCaml) by disabling
> String.set in the standard library (the s.[i] <- c construct is just sugar
> for a call to that function).

And removing the other functions of String module which mutates strings
(actually I've made an experiment in which I removed string mutability).

> Is there a better approach to polymorphic equality floating around?

Type classes!

-- 
Nicolas Pouillard
http://nicolaspouillard.fr

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

[Jon Harrop]

> Is there a better approach to polymorphic equality floating around?

SML's equality types are simpler than type classes and more robust than
OCaml's polymorphic equality (and comparison, and hashing). F# uses equality
types.

Cheers,
Jon.