[Caml-list] off-brand use of ocaml bytecode

[Caml-list] off-brand use of ocaml bytecode

[Hendrik Boom]

Are there ny tools available that could be used to generate ocaml 
bytecode for other languages? 

If I were to do that, by hand or otherwise, how would I interpret or 
compile it?

Would the ocaml run-time system we available -- things like the garbage 
collector, I/O libraries, etc.

Is anyone else working of projects like this?

-- hendrik

Re: [Caml-list] off-brand use of ocaml bytecode

[Evgeny Roubinchtein]

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

I know there are people on this list who are way more qualified to answer
these questions, but let me try.

On Wed, Dec 21, 2016 at 8:12 PM, Hendrik Boom <hendrik@topoi.pooq.com>
wrote:

> Are there ny tools available that could be used to generate ocaml
> bytecode for other languages?
>

I don't think you will get a definitive answer on this list.   Here is a
thought experiment showing why.  Suppose J. Random Hacker decides to write
a compiler from WhizBangLang to OCaml byte code.  Under the assumption that
OCaml developers are not omniscient, the way they would learn about J.
Random Hacker's efforts is if s/he either: a) announces the new language in
some venue that OCaml developers watch or b) finds [what s/he believes are]
bugs in the OCaml byte code interpreter and files bug reports against it.
It isn't clear to me that our J Random Hacker must needs do either of those
things.

If I were to do that, by hand or otherwise, how would I interpret or
> compile it?
>

The ocamlrun program, shipped with the OCaml distribution and documented at
http://caml.inria.fr/pub/docs/manual-ocaml/runtime.html is the standard
interpreter for the OCaml byte code.

For the OCaml compiler, the byte code is a target (as opposed to a source
or an intermediate representation), so the existing OCaml tool chain does
not support compiling byte code, to the best of my knowledge (AFAIK
projects like Bucklescript and js_of_ocaml use the OCaml front-end and
intermediate representation, but supply a different compiler back end).

Would the ocaml run-time system we available -- things like the garbage
> collector, I/O libraries, etc.
>

I think that question is answered in the documentation of ocamlrun.   You
probably will also want to peruse
http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html and specifically the
discussion of static and dynamic linking of C code with OCaml code.


> Is anyone else working of projects like this?


I am not entirely certain what the intended antecedent of "this" is here.
If "this" is "a compiler that targets OCaml byte code", then please see my
answer above.  If you feel that the current design of "ocamlrun for
standard primitives + the '-custom' flag to the OCaml compiler for
non-standard primitives" is failing to address a need, then a description
of the need that isn't being addressed would be a good starting point for
discussion. ;-)

Hope this helps
-- 
Best,
Zhenya

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

Re: [Caml-list] off-brand use of ocaml bytecode

[Yotam Barnoy]

Check out Stephen Dolan's Malfunction
(https://github.com/stedolan/malfunction). You essentially compile
down to OCaml's internal representation, and the compiler takes it
from there, making either bytecode or native binaries.

On Thu, Dec 22, 2016 at 10:48 AM, Evgeny Roubinchtein
<zhenya1007@gmail.com> wrote:
> I know there are people on this list who are way more qualified to answer
> these questions, but let me try.
>
> On Wed, Dec 21, 2016 at 8:12 PM, Hendrik Boom <hendrik@topoi.pooq.com>
> wrote:
>>
>> Are there ny tools available that could be used to generate ocaml
>> bytecode for other languages?
>
>
> I don't think you will get a definitive answer on this list.   Here is a
> thought experiment showing why.  Suppose J. Random Hacker decides to write a
> compiler from WhizBangLang to OCaml byte code.  Under the assumption that
> OCaml developers are not omniscient, the way they would learn about J.
> Random Hacker's efforts is if s/he either: a) announces the new language in
> some venue that OCaml developers watch or b) finds [what s/he believes are]
> bugs in the OCaml byte code interpreter and files bug reports against it.
> It isn't clear to me that our J Random Hacker must needs do either of those
> things.
>
>> If I were to do that, by hand or otherwise, how would I interpret or
>> compile it?
>
>
> The ocamlrun program, shipped with the OCaml distribution and documented at
> http://caml.inria.fr/pub/docs/manual-ocaml/runtime.html is the standard
> interpreter for the OCaml byte code.
>
> For the OCaml compiler, the byte code is a target (as opposed to a source or
> an intermediate representation), so the existing OCaml tool chain does not
> support compiling byte code, to the best of my knowledge (AFAIK projects
> like Bucklescript and js_of_ocaml use the OCaml front-end and intermediate
> representation, but supply a different compiler back end).
>
>> Would the ocaml run-time system we available -- things like the garbage
>> collector, I/O libraries, etc.
>
>
> I think that question is answered in the documentation of ocamlrun.   You
> probably will also want to peruse
> http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html and specifically the
> discussion of static and dynamic linking of C code with OCaml code.
>
>>
>> Is anyone else working of projects like this?
>
>
> I am not entirely certain what the intended antecedent of "this" is here.
> If "this" is "a compiler that targets OCaml byte code", then please see my
> answer above.  If you feel that the current design of "ocamlrun for standard
> primitives + the '-custom' flag to the OCaml compiler for non-standard
> primitives" is failing to address a need, then a description of the need
> that isn't being addressed would be a good starting point for discussion.
> ;-)
>
> Hope this helps
> --
> Best,
> Zhenya
>

Re: [Caml-list] off-brand use of ocaml bytecode

[Gabriel Scherer]

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

There is one known case of the OCaml runtime being reused, namely the Coq
bytecode interpreter, which is a modified version of the OCaml bytecode
interpreter that supports a different evaluation strategy. This is
described in the article

  A Compiled Implementation of Strong Reduction
  Benjamin Grégoire and Xavier Leroy, 2002
  http://gallium.inria.fr/~xleroy/publi/strong-reduction.pdf

This implementation duplicates (and simplifies) the instruction set and
interpretation loop, but it does reuse the same value representation and, I
believe, the OCaml runtime system (the GC in particular).

If you are interested in a documentation of the OCaml bytecode runtime, the
two following documents could be of help:
- Benedikt Meurer's article on his work on jitting the bytecode runtime
begins with a very clear how-level description of how the whole thing works
in OCaml today: https://arxiv.org/abs/1011.1783
- Xavier Clerc, while working on OCamlJava, produced a very detailed and
up-to-date reference of the OCaml bytecode instruction set (
http://cadmium.x9c.fr/distrib/caml-instructions.pdf )

(A more high-level description of the principles behind the instruction
set, in particular how it makes curried functions fast enough, can be found
in Xavier Leroy's course notes on "abstract machines and compilation",
along with comparisons with other designs of the 80s or early 90s and some
correctness proofs:
  http://gallium.inria.fr/~xleroy/mpri/2-4/machines.pdf
)

On Thu, Dec 22, 2016 at 10:48 AM, Evgeny Roubinchtein <zhenya1007@gmail.com>
wrote:

> I know there are people on this list who are way more qualified to answer
> these questions, but let me try.
>
> On Wed, Dec 21, 2016 at 8:12 PM, Hendrik Boom <hendrik@topoi.pooq.com>
> wrote:
>
>> Are there ny tools available that could be used to generate ocaml
>> bytecode for other languages?
>>
>
> I don't think you will get a definitive answer on this list.   Here is a
> thought experiment showing why.  Suppose J. Random Hacker decides to write
> a compiler from WhizBangLang to OCaml byte code.  Under the assumption that
> OCaml developers are not omniscient, the way they would learn about J.
> Random Hacker's efforts is if s/he either: a) announces the new language in
> some venue that OCaml developers watch or b) finds [what s/he believes are]
> bugs in the OCaml byte code interpreter and files bug reports against it.
> It isn't clear to me that our J Random Hacker must needs do either of those
> things.
>
> If I were to do that, by hand or otherwise, how would I interpret or
>> compile it?
>>
>
> The ocamlrun program, shipped with the OCaml distribution and documented
> at http://caml.inria.fr/pub/docs/manual-ocaml/runtime.html is the
> standard interpreter for the OCaml byte code.
>
> For the OCaml compiler, the byte code is a target (as opposed to a source
> or an intermediate representation), so the existing OCaml tool chain does
> not support compiling byte code, to the best of my knowledge (AFAIK
> projects like Bucklescript and js_of_ocaml use the OCaml front-end and
> intermediate representation, but supply a different compiler back end).
>
> Would the ocaml run-time system we available -- things like the garbage
>> collector, I/O libraries, etc.
>>
>
> I think that question is answered in the documentation of ocamlrun.   You
> probably will also want to peruse http://caml.inria.fr/
> pub/docs/manual-ocaml/intfc.html and specifically the discussion of
> static and dynamic linking of C code with OCaml code.
>
>
>> Is anyone else working of projects like this?
>
>
> I am not entirely certain what the intended antecedent of "this" is here.
> If "this" is "a compiler that targets OCaml byte code", then please see my
> answer above.  If you feel that the current design of "ocamlrun for
> standard primitives + the '-custom' flag to the OCaml compiler for
> non-standard primitives" is failing to address a need, then a description
> of the need that isn't being addressed would be a good starting point for
> discussion. ;-)
>
> Hope this helps
> --
> Best,
> Zhenya
>
>

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

[Caml-list] off-brand use of ocaml's lambda IR.

[Hendrik Boom]

On Wed, Dec 21, 2016 at 08:12:31PM -0500, Hendrik Boom wrote:
> Are there ny tools available that could be used to generate ocaml 
> bytecode for other languages? 
> 
> If I were to do that, by hand or otherwise, how would I interpret or 
> compile it?
> 
> Would the ocaml run-time system we available -- things like the garbage 
> collector, I/O libraries, etc.
> 
> Is anyone else working of projects like this?
> 
> -- hendrik

Having started to leaf through a few pieces of documentation about
the OCaml compilation chain, I now figure that the lambda IR would 
probably be a better place to tap into the process. 

So I'll re-ask, this time sking about compiling from the internal lambda 
representation instead of the byte-code.

-- hendrik

Re: [Caml-list] off-brand use of ocaml's lambda IR.

[Gabriel Scherer]

Maybe you should indeed consider Malfunction as Yotam mentioned in the
previous thread:
  https://github.com/stedolan/malfunction

It is a well-defined language made for producing code to go into the
OCaml compilation pipeline. You can think of it as a subset of the
lambda intermediate language, with a fixed (s-expressions) syntax and
parser, and a documentation of the behavior of its programs.

It is a bit simplistic (or at least it was last time I looked) but if
you have extra needs you could get in touch with the author (Stephen
Dolan) and work with him to extend it.

On Thu, Dec 22, 2016 at 5:18 PM, Hendrik Boom <hendrik@topoi.pooq.com> wrote:
> On Wed, Dec 21, 2016 at 08:12:31PM -0500, Hendrik Boom wrote:
>> Are there ny tools available that could be used to generate ocaml
>> bytecode for other languages?
>>
>> If I were to do that, by hand or otherwise, how would I interpret or
>> compile it?
>>
>> Would the ocaml run-time system we available -- things like the garbage
>> collector, I/O libraries, etc.
>>
>> Is anyone else working of projects like this?
>>
>> -- hendrik
>
> Having started to leaf through a few pieces of documentation about
> the OCaml compilation chain, I now figure that the lambda IR would
> probably be a better place to tap into the process.
>
> So I'll re-ask, this time sking about compiling from the internal lambda
> representation instead of the byte-code.
>
> -- hendrik
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs