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

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

[ivan chollet]

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

I have noted that there are now many implementation of OCaml. Namely :
- caml light
- jocaml
- mincaml
- your implementation ?
etc.

which means there is a lot of interest in implementing tools and runtimes
for ML.
I'm just saying this because I was planning to implement another VM for ML
to address my own needs.
Well, now I'm thinking that the community should start a project like Parrot
(with JIT optionally) but dedicated to ML. The existing ocaml runtime is
amazing but it's definitely not very community friendly and is in my opinion
a bit hard to understand given the scarcity of design documents. A real
community project with real documentation might be interesting for teaching
purposes but also in production environments.
If enough people are interested, I'll be happy to contribute or to start
such a project.
What do you think?

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

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

[Cedric Cellier]

-[ Mon, Aug 09, 2010 at 04:37:36PM +1000, ivan chollet ]----
> The existing ocaml runtime is
> amazing but it's definitely not very community friendly and is in my opinion
> a bit hard to understand given the scarcity of design documents. A real
> community project with real documentation might be interesting for teaching
> purposes but also in production environments.
> If enough people are interested, I'll be happy to contribute or to start
> such a project.

Don't you think it would be a more profitable work to document the
existing runtime instead ?

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

[ivan chollet]

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

It guess it would, but it seems to me that such a task would be far too
ambitious.
Speaking for myself, I could relatively quickly write a VM for caml, but
writing the ocaml runtime design documents is something that would take me
way too much time. Most of ML users don't have access to the original caml
designers so we have no way to understand their design choices fully.


-[ Mon, Aug 09, 2010 at 04:37:36PM +1000, ivan chollet ]----
> The existing ocaml runtime is
> amazing but it's definitely not very community friendly and is in my opinion
> a bit hard to understand given the scarcity of design documents. A real
> community project with real documentation might be interesting for teaching
> purposes but also in production environments.
> If enough people are interested, I'll be happy to contribute or to start
> such a project.

Don't you think it would be a more profitable work to document the
existing runtime instead ?


>
>

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

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

[ivan chollet]

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

It guess it would, however it seems to me that such a task would be far too
ambitious.
Speaking for myself, I could relatively quickly write a VM for caml, but
writing the ocaml runtime design documents is something that would take me
way too much time. Most of ML users don't have access to the original caml
designers so we have no way to understand their design choices fully.
Having said that, the two tasks are non exclusive so we can definitely start
a project with all these goals in mind.

-[ Mon, Aug 09, 2010 at 04:37:36PM +1000, ivan chollet ]----
> The existing ocaml runtime is
> amazing but it's definitely not very community friendly and is in my opinion
> a bit hard to understand given the scarcity of design documents. A real
> community project with real documentation might be interesting for teaching
> purposes but also in production environments.
> If enough people are interested, I'll be happy to contribute or to start
> such a project.

Don't you think it would be a more profitable work to document the
existing runtime instead ?


>
>

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

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

[Jon Harrop]

Ivan wrote:
> I have noted that there are now many implementation of OCaml. Namely :
> - caml light
> - jocaml
> - mincaml
> - your implementation ?
> etc.
>
> which means there is a lot of interest in implementing tools and runtimes
for ML. 

I'm not sure 3.5 implementations over 25 years is a "lot" of interest but
maybe if you add HLVM... ;-)

> Well, now I'm thinking that the community should start a project like
Parrot (with JIT optionally)
> but dedicated to ML.

I already did something like this called HLVM:

  http://www.ffconsultancy.com/ocaml/hlvm/

> The existing ocaml runtime is amazing but it's definitely not very
community friendly and is in my
> opinion a bit hard to understand given the scarcity of design documents.

Feel free to ask me anything about HLVM's design. We have a dedicated
mailing list:

  https://lists.forge.ocamlcore.org/pipermail/hlvm-list/

> A real community project with real documentation might be interesting for
teaching purposes but also
> in production environments.

HLVM might be interesting for teaching purposes because it is tiny (2kLOC)
and comprehensible whilst providing advanced features like JIT compilation
(for a native-code REPL!) and a multicore-capable garbage collector (in only
100LOC!). HLVM should also be suitable for production environments.

I had actually forgotten about the mincaml project but mincaml's front-end
with HLVM's back-end sounds like a match made in heaven...

Cheers,
Jon.

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

[philippe]

I'm really far from beeing a compiler expert, but an ocaml user geared
toward numerical applications devel.

while doing a net search, I found this paper about array computations
optimizations which may be of interest to you:

http://www.google.com/url?sa=t&source=web&cd=1&ved=0CBIQFjAA&url=http%3A%2F%2Fwww.cs.cornell.edu%2Fcourses%2Fcs612%2F2001sp%2Fprojects%2Focaml-arrays%2FOCaml.pdf&ei=YstiTOPeIpCFOMfEkIAK&usg=AFQjCNGT7H1DLo3_I0e_61j1KXLrqFSXjg&sig2=79dGgmdIe-aH1aSqC8CWVQ

or google/whatever... and search "Array Optimizations in OCaml"

--
Ph. Strauss

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

[ivan chollet]

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

+ HLVM, Moscow ML, MLTon, etc.
Not too bad in my opinion.

I checked your HLVM and it looks like a really nice project. I had heard
about it before but to be honest it's hard to find information about its
design. Maybe you should release the design documents publicly. It could be
also an good incentive for people to subscribe to your journal.
I looked at the source and I have to say i like it for its simplicity. What
I dislike is that your bytecode runs on LLVM, which is a general purpose
virtual machine, and because it's general purpose, the bytecode and thus the
JIT is a lot more complicated than if the whole infrastructure  was for ML
and ML only. My personal opinion is that the idiosyncrasies of ML deserve
more elegant than this complicated piece of code.
And what i dislike is to debug big pieces of code like this myself
(especially when there is no documentation like with OCaml).

So after reading a few things about HLVM, what I have in mind is basically
the same thing as you did, with only a few minor differences :
- the project should have it's own runtime (with runtime i mean interpreter
+ garbage collector only)
- no need for a JIT at the beginning
- less emphasis on performance at the beginning
- less emphasis on features (your project looks very ambitious in terms of
supported features)
- more emphasis on code safety (than ocaml at least, i don't like to see
segmentation faults). LLVM is not that strong on debugging and code safety
than some other VMs are. (that's just what i've heard and I might be plain
wrong here, but i'm unable to check it myself because LLVM source code is
too complicated for me)
- more emphasis on simplicity and interfaces loosely coupling
- a LOT more emphasis on being community friendly and providing design
documents (for free...)


Now I have to say that LLVM is an amazing project (so is HLVM), and if you
need to have an ML implementation up quickly with good performance and lots
of features supported, then I would admit that this is the only way to go at
the moment. There is no way the community around ML in general and OCaml
specifically would ever come up in the next 10 years with such a
feature-rich runtime and compiler infrastructure.
But now that VMs are becoming a commodity and there is a lot of literature
and resources on the topic, it is also not very time consuming to pull
something from the ground up.
I would be interested to hear your opinion on this.


On Wed, Aug 11, 2010 at 11:19 PM, Jon Harrop <
jonathandeanharrop@googlemail.com> wrote:

> Ivan wrote:
> > I have noted that there are now many implementation of OCaml. Namely :
> > - caml light
> > - jocaml
> > - mincaml
> > - your implementation ?
> > etc.
> >
> > which means there is a lot of interest in implementing tools and runtimes
> for ML.
>
> I'm not sure 3.5 implementations over 25 years is a "lot" of interest but
> maybe if you add HLVM... ;-)
>
> > Well, now I'm thinking that the community should start a project like
> Parrot (with JIT optionally)
> > but dedicated to ML.
>
> I already did something like this called HLVM:
>
>  http://www.ffconsultancy.com/ocaml/hlvm/
>
> > The existing ocaml runtime is amazing but it's definitely not very
> community friendly and is in my
> > opinion a bit hard to understand given the scarcity of design documents.
>
> Feel free to ask me anything about HLVM's design. We have a dedicated
> mailing list:
>
>  https://lists.forge.ocamlcore.org/pipermail/hlvm-list/
>
> > A real community project with real documentation might be interesting for
> teaching purposes but also
> > in production environments.
>
> HLVM might be interesting for teaching purposes because it is tiny (2kLOC)
> and comprehensible whilst providing advanced features like JIT compilation
> (for a native-code REPL!) and a multicore-capable garbage collector (in
> only
> 100LOC!). HLVM should also be suitable for production environments.
>
> I had actually forgotten about the mincaml project but mincaml's front-end
> with HLVM's back-end sounds like a match made in heaven...
>
> Cheers,
> Jon.
>
>
>

[-- Attachment #2: Type: text/html, Size: 4958 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?

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

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

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

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

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?

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

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

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

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

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

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

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

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

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

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

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