+ 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
) would be worth putting in a
minimalistic language because it is so useful.
Cheers,
Jon.
From: Jeremy Bem [mailto:jere...@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
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
-[ 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
On Sun, 8 Aug 2010 15:39:28 -0400, Jeremy Bem jere...@gmail.com wrote:
On Sun, Aug 8, 2010 at 2:52 PM, Florian Weimer f...@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
On 8 August 2010 17:47, bluestorm bluestorm.d...@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
On Mon, 9 Aug 2010 09:10:43 -0400, David House dmho...@gmail.com wrote:
On 8 August 2010 17:47, bluestorm bluestorm.d...@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
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
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
* 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
On Sun, Aug 8, 2010 at 1:59 PM, Florian Weimer f...@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
* 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
On Sun, Aug 8, 2010 at 2:52 PM, Florian Weimer f...@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
On Sun, 8 Aug 2010 14:44:11 -0400, Jeremy Bem jere...@gmail.com wrote:
On Sun, Aug 8, 2010 at 1:59 PM, Florian Weimer f...@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
On Sun, 08 Aug 2010 20:52:53 +0200, Florian Weimer f...@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.
On Sun, Aug 8, 2010 at 4:53 PM, Nicolas Pouillard
nicolas.pouill...@gmail.com wrote:
On Sun, 08 Aug 2010 20:52:53 +0200, Florian Weimer f...@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
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
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
On Sun, Aug 8, 2010 at 5:47 PM, bluestorm bluestorm.d...@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
On Fri, Aug 6, 2010 at 7:04 AM, Jeremy Bem jere...@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,
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
21 matches
Mail list logo
