[Caml-list] ANN: BER MetaOCaml N104, for OCaml 4.04.0

[Caml-list] ANN: BER MetaOCaml N104, for OCaml 4.04.0

[Oleg]

BER MetaOCaml N104 is a strict superset of OCaml 4.04.0 for ``writing
programs that generate programs''.  BER MetaOCaml adds to OCaml the
type of code values (denoting ``program code'', or future-stage
computations), and two basic constructs to build them:
quoting and splicing. The generated code can be printed, stored in a
file -- or compiled and linked-back to the running program, thus
implementing run-time code optimization. A well-typed BER MetaOCaml
program generates only well-scoped and well-typed programs: 
The generated code shall compile without type errors. 
Staging-annotation-free BER MetaOCaml is identical to
OCaml; BER MetaOCaml can link to any OCaml-compiled library (and
vice versa); findlib and other tools can be used with BER MetaOCaml as
they are, in their binary form.

BER MetaOCaml N104 comes with one minor and two notable improvements.
The minor improvement is the availability of the native MetaOCaml.  If
the generator is compiled in native mode (using metaocamlopt), the
dynamically generated and run code will be natively-compiled as
well. The lack of native mode was the most frequently heard criticism
of MetaOCaml, although in my experience it hardly even
matters. Off-line code specialization seems to be far more prevalent
and useful than online one. Anyway, here we have it.

The notable new features -- not seen in MetaOCaml (or MetaML, for that
matter) -- are generating pattern-matching expression with the
statically unknown number of clauses, and let-insertion as a
primitive. To wit, |genlet exp| inserts  |let freshname = exp in ...| 
somewhere in the generated code and returns |.<freshname>.| (unless |exp|
is already syntactically a value such as a variable reference).
The let-statement is inserted at the most appropriate place.

BER MetaOCaml N104 should be available though OPAM, hopefully soon.
In the meanwhile, it is available as a set of patches to the 
OCaml 4.04.0 distribution. 
        http://okmij.org/ftp/ML/ber-metaocaml-104.tar.gz
See the INSTALL document in that archive. You need the source
distribution of OCaml 4.04.0, see the following URL for details.

For more explanations, please see
        http://okmij.org/ftp/ML/MetaOCaml.html
as well as ChangeLog and NOTES.txt in the BER MetaOCaml distribution.

Re: [Caml-list] ANN: BER MetaOCaml N104, for OCaml 4.04.0

[Gabriel Scherer]

Congratulations on this interesting new release.

Below are some minor remarks I had while looking at what you wrote on
this release and its new features.

One. I am not familiar with the MetaOCaml implementation but,
intuitively, I wondered why attributes were used instead of
extensions. In my book, (e [@attr]) is supposed to be an OCaml term
that behaves as the expression (e), with some extra (tooling- or
optimization- related) expression of intent. On the contrary, [%ext e]
is allowed to have any semantics at all. One could even argue that it
is semantically wrong to use attributes for MetaOCaml (as their forms
do change the semantics), although that concern is alleviated by the
use of the foreign-looking syntax .< ... >. which also indicates that
something non-standard is going on.

One interesting thing with the addition of the two new syntactic
classes "pattern" and "value" is that, from a syntactic point of view,
the idea of using extensions directly instead of home-grown syntax
starts looking more reasonable: [%quote e], [%quote.pat e],
[%quote.val e] (plus long forms metaocaml.quote*). Moving from .< e >.
to [%quote e] is still arguably a bad deal for readability, but for
the other two forms it would actually be an improvement over the
current syntax. So I guess the benefit would depend a lot on how often
these two new forms end up being used by MetaOCaml programmers. Using
the extension syntax directly would certainly simplify a few things
around MetaOCaml -- zero need for non-standard parsing, for example.

Two. It is interesting that you mention that "function" allows to
easily represent sets of clauses as expressions, as I was recently
thinking about which kind of constructions would be made possible by
taking "sets of clauses" as a first-class syntactic category.

Three. I was professionally obligated to remark your formulation on
where (genlet exp) actually places its definition: "The `let` is
inserted right under the binder for the "latest" free variable
contained in `exp`". This is exactly the style of placement used in
sum-equivalence algorithms (and, I suppose, work on partial
evaluation), typically the delimited-control-using presentation of
"Extensional normalisation and type-directed partial evaluation for
typed lambda calculus with sums" by Vincent Balat, Roberto Di Cosmo
and Marcelo Fiore, 2004. Interestingly, these algorithms do not (only)
place let-bindings in this way, but also case statements -- they want
the case-distinction on the bound value to have as large a scope as
possible. This suggests that maybe the "finding the earliest place to
introduce an expression" is a really useful primitive to have for
metaprogramming, and that your "genlet" could be reconstructed from
it, but right now I don't see how to expose it without letting the
user do delimited control -- which is what you started from.

On Sun, Jan 1, 2017 at 10:20 AM, Oleg <oleg@okmij.org> wrote:
>
> BER MetaOCaml N104 is a strict superset of OCaml 4.04.0 for ``writing
> programs that generate programs''.  BER MetaOCaml adds to OCaml the
> type of code values (denoting ``program code'', or future-stage
> computations), and two basic constructs to build them:
> quoting and splicing. The generated code can be printed, stored in a
> file -- or compiled and linked-back to the running program, thus
> implementing run-time code optimization. A well-typed BER MetaOCaml
> program generates only well-scoped and well-typed programs:
> The generated code shall compile without type errors.
> Staging-annotation-free BER MetaOCaml is identical to
> OCaml; BER MetaOCaml can link to any OCaml-compiled library (and
> vice versa); findlib and other tools can be used with BER MetaOCaml as
> they are, in their binary form.
>
> BER MetaOCaml N104 comes with one minor and two notable improvements.
> The minor improvement is the availability of the native MetaOCaml.  If
> the generator is compiled in native mode (using metaocamlopt), the
> dynamically generated and run code will be natively-compiled as
> well. The lack of native mode was the most frequently heard criticism
> of MetaOCaml, although in my experience it hardly even
> matters. Off-line code specialization seems to be far more prevalent
> and useful than online one. Anyway, here we have it.
>
> The notable new features -- not seen in MetaOCaml (or MetaML, for that
> matter) -- are generating pattern-matching expression with the
> statically unknown number of clauses, and let-insertion as a
> primitive. To wit, |genlet exp| inserts  |let freshname = exp in ...|
> somewhere in the generated code and returns |.<freshname>.| (unless |exp|
> is already syntactically a value such as a variable reference).
> The let-statement is inserted at the most appropriate place.
>
> BER MetaOCaml N104 should be available though OPAM, hopefully soon.
> In the meanwhile, it is available as a set of patches to the
> OCaml 4.04.0 distribution.
>         http://okmij.org/ftp/ML/ber-metaocaml-104.tar.gz
> See the INSTALL document in that archive. You need the source
> distribution of OCaml 4.04.0, see the following URL for details.
>
> For more explanations, please see
>         http://okmij.org/ftp/ML/MetaOCaml.html
> as well as ChangeLog and NOTES.txt in the BER MetaOCaml distribution.
>
>
> --
> 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

Re: [Caml-list] ANN: BER MetaOCaml N104, for OCaml 4.04.0

[Manfred Lotz]

On Sun, 1 Jan 2017 11:03:56 -0500
Gabriel Scherer <gabriel.scherer@gmail.com> wrote:

> In my book, (e [@attr]) is supposed to be an OCaml term
> that behaves as the expression (e), with some extra (tooling- or
> optimization- related) expression of intent.   

I see you mentioning 'my book' for the second time. Where is your book
to be found?


-- 
Manfred

Re: [Caml-list] ANN: BER MetaOCaml N104, for OCaml 4.04.0

[Gabriel Scherer]

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

This is just an idiom to say "in my opinion" (my reading is more "according
to my personal view of the world"), and I have no idea where I took it
from. Apologies for the confusion.

On Sun, Jan 1, 2017 at 2:25 PM, Manfred Lotz <manfred.lotz@arcor.de> wrote:

> On Sun, 1 Jan 2017 11:03:56 -0500
> Gabriel Scherer <gabriel.scherer@gmail.com> wrote:
>
> > In my book, (e [@attr]) is supposed to be an OCaml term
> > that behaves as the expression (e), with some extra (tooling- or
> > optimization- related) expression of intent.
>
> I see you mentioning 'my book' for the second time. Where is your book
> to be found?
>
>
> --
> Manfred
>
> --
> 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
>

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

Re: [Caml-list] ANN: BER MetaOCaml N104, for OCaml 4.04.0

[Manfred Lotz]

On Sun, 1 Jan 2017 14:34:29 -0500
Gabriel Scherer <gabriel.scherer@gmail.com> wrote:

> This is just an idiom to say "in my opinion" (my reading is more
> "according to my personal view of the world"), and I have no idea
> where I took it from. 

I see. Didn't know that idiom.

> Apologies for the confusion.

No prob. 



> On Sun, Jan 1, 2017 at 2:25 PM, Manfred Lotz <manfred.lotz@arcor.de>
> wrote:
> 
> > On Sun, 1 Jan 2017 11:03:56 -0500
> > Gabriel Scherer <gabriel.scherer@gmail.com> wrote:
> >  
> > > In my book, (e [@attr]) is supposed to be an OCaml term
> > > that behaves as the expression (e), with some extra (tooling- or
> > > optimization- related) expression of intent.  
> >
> > I see you mentioning 'my book' for the second time. Where is your
> > book to be found?
> >
> >
> > --
> > Manfred
> >
> > --
> > 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
> >  
> 

Re: [Caml-list] ANN: BER MetaOCaml N104, for OCaml 4.04.0

[Eray Ozkural]

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

This sounds far better than a minor improvement, for many macro-like apps
this would be a major roadblock as there is a big performance gap in
interpreted and compiled code in ocaml. Could be a game changer.
Congratulations Oleg!

Best,

Eray

On Sun, Jan 1, 2017 at 6:20 PM, Oleg <oleg@okmij.org> wrote:

>
> BER MetaOCaml N104 is a strict superset of OCaml 4.04.0 for ``writing
> programs that generate programs''.  BER MetaOCaml adds to OCaml the
> type of code values (denoting ``program code'', or future-stage
> computations), and two basic constructs to build them:
> quoting and splicing. The generated code can be printed, stored in a
> file -- or compiled and linked-back to the running program, thus
> implementing run-time code optimization. A well-typed BER MetaOCaml
> program generates only well-scoped and well-typed programs:
> The generated code shall compile without type errors.
> Staging-annotation-free BER MetaOCaml is identical to
> OCaml; BER MetaOCaml can link to any OCaml-compiled library (and
> vice versa); findlib and other tools can be used with BER MetaOCaml as
> they are, in their binary form.
>
> BER MetaOCaml N104 comes with one minor and two notable improvements.
> The minor improvement is the availability of the native MetaOCaml.  If
> the generator is compiled in native mode (using metaocamlopt), the
> dynamically generated and run code will be natively-compiled as
> well. The lack of native mode was the most frequently heard criticism
> of MetaOCaml, although in my experience it hardly even
> matters. Off-line code specialization seems to be far more prevalent
> and useful than online one. Anyway, here we have it.
>
> The notable new features -- not seen in MetaOCaml (or MetaML, for that
> matter) -- are generating pattern-matching expression with the
> statically unknown number of clauses, and let-insertion as a
> primitive. To wit, |genlet exp| inserts  |let freshname = exp in ...|
> somewhere in the generated code and returns |.<freshname>.| (unless |exp|
> is already syntactically a value such as a variable reference).
> The let-statement is inserted at the most appropriate place.
>
> BER MetaOCaml N104 should be available though OPAM, hopefully soon.
> In the meanwhile, it is available as a set of patches to the
> OCaml 4.04.0 distribution.
>         http://okmij.org/ftp/ML/ber-metaocaml-104.tar.gz
> See the INSTALL document in that archive. You need the source
> distribution of OCaml 4.04.0, see the following URL for details.
>
> For more explanations, please see
>         http://okmij.org/ftp/ML/MetaOCaml.html
> as well as ChangeLog and NOTES.txt in the BER MetaOCaml distribution.
>
>
> --
> 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
>



-- 
Eray Ozkural, PhD. Computer Scientist
Founder, Gok Us Sibernetik Ar&Ge Ltd.
http://groups.yahoo.com/group/ai-philosophy

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

Re: [Caml-list] ANN: BER MetaOCaml N104, for OCaml 4.04.0

[Oleg]

Thank you, Gabriel. Sorry for a late reply.

> I wondered why attributes were used instead of
> extensions. 
I have thought about this issue and have documented the reasoning
behind settling on attributes in the NOTES.txt file of the metalib
directory. That file describes many other design decisions, possible
alternatives, and future work.

> In my book, (e [@attr]) is supposed to be an OCaml term
> that behaves as the expression (e), with some extra (tooling- or
> optimization- related) expression of intent. On the contrary, [%ext e]
> is allowed to have any semantics at all. 

That is precisely the reason. The type-checker traverses an expression
several times (e.g., to collect variables, to check expansiveness,
etc.) It totally ignores the extension nodes. But it traverses inside
the nodes with attached attributes. This is the behavior I want. The
expression inside the brackets is meant to be a regular OCaml
expression (only evaluated with a `delay', so to speak), so the
typechecker should go inside and check it, etc. If I used extensions,
I would need to emulate these extra typechecking traversals somehow.
Incidentally, staging literature very often calls brackets and escapes
``staging _annotations_''. There is a reason for that.

> One interesting thing with the addition of the two new syntactic
> classes "pattern" and "value" is that, from a syntactic point of view,
> the idea of using extensions directly instead of home-grown syntax
> starts looking more reasonable: [%quote e], [%quote.pat e],
> [%quote.val e] (plus long forms metaocaml.quote*). Moving from .< e >.
> to [%quote e] is still arguably a bad deal for readability, but for
> the other two forms it would actually be an improvement over the
> current syntax. So I guess the benefit would depend a lot on how often
> these two new forms end up being used by MetaOCaml programmers. Using
> the extension syntax directly would certainly simplify a few things
> around MetaOCaml -- zero need for non-standard parsing, for example.

I fully agree with that. [%quote.pat e] is certainly very
appealing. Perhaps we can check carefully how OCaml traverses
expressions (besides the normal typechecking pass) and if using
extension will be sufficient in the end. If so, one can easily switch
to it.

> It is interesting that you mention that "function" allows to
> easily represent sets of clauses as expressions, as I was recently
> thinking about which kind of constructions would be made possible by
> taking "sets of clauses" as a first-class syntactic category.
We can discuss this further in a couple of days. Some unification will
be nice.

> I was professionally obligated to remark your formulation on
> where (genlet exp) actually places its definition: "The `let` is
> inserted right under the binder for the "latest" free variable
> contained in `exp`". This is exactly the style of placement used in
> sum-equivalence algorithms (and, I suppose, work on partial
> evaluation), typically the delimited-control-using presentation of
> "Extensional normalisation and type-directed partial evaluation for
> typed lambda calculus with sums" by Vincent Balat, Roberto Di Cosmo
> and Marcelo Fiore, 2004. Interestingly, these algorithms do not (only)
> place let-bindings in this way, but also case statements -- they want
> the case-distinction on the bound value to have as large a scope as
> possible. This suggests that maybe the "finding the earliest place to
> introduce an expression" is a really useful primitive to have for
> metaprogramming, and that your "genlet" could be reconstructed from
> it, but right now I don't see how to expose it without letting the
> user do delimited control -- which is what you started from.
As you probably expect, I am well familiar with Balat works and NBE
and the problem of placing let and case statements. Before I used
delimited control. But the current implementation of MetaOCaml does
something different. Internally, a code value is represented as
AST along with a set of `virtual' let-bindings. That is, essentially
in the form
        let x1 = e1 and x2 = e2 ... in e
That should remind you of `answers' used in call-by-need calculi.
The virtual bindings are converted to real let-bindings when the
binder is applied to the expression. If the bound variable occurs
within ei, the corresponding virtual let-binding must be made real.
Others remain virtual and float out. Of course there are
complications: an expression may be spliced in
several times. So, one has to deal with duplicates. Further, genlet
may nest (that is, each ei itself contains virtual let-bindings. When
actualizing let-bindings, we have to `straighten them up'). The
comments in the main code file trx.ml describe the algorithm in some
detail. It should be written up of course. Again, this is something we
can talk about in a day.

Re: [Caml-list] ANN: BER MetaOCaml N104, for OCaml 4.04.0

[Eray Ozkural]

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

Hi Oleg,

I have a question. Have you ever designed at length how to implement a
super fast *interpreted* version of metaocaml, or let me put it this way:
do you think if that is possible at all?

Best,

Eray

On Sun, Jan 1, 2017 at 6:20 PM, Oleg <oleg@okmij.org> wrote:

>
> BER MetaOCaml N104 is a strict superset of OCaml 4.04.0 for ``writing
> programs that generate programs''.  BER MetaOCaml adds to OCaml the
> type of code values (denoting ``program code'', or future-stage
> computations), and two basic constructs to build them:
> quoting and splicing. The generated code can be printed, stored in a
> file -- or compiled and linked-back to the running program, thus
> implementing run-time code optimization. A well-typed BER MetaOCaml
> program generates only well-scoped and well-typed programs:
> The generated code shall compile without type errors.
> Staging-annotation-free BER MetaOCaml is identical to
> OCaml; BER MetaOCaml can link to any OCaml-compiled library (and
> vice versa); findlib and other tools can be used with BER MetaOCaml as
> they are, in their binary form.
>
> BER MetaOCaml N104 comes with one minor and two notable improvements.
> The minor improvement is the availability of the native MetaOCaml.  If
> the generator is compiled in native mode (using metaocamlopt), the
> dynamically generated and run code will be natively-compiled as
> well. The lack of native mode was the most frequently heard criticism
> of MetaOCaml, although in my experience it hardly even
> matters. Off-line code specialization seems to be far more prevalent
> and useful than online one. Anyway, here we have it.
>
> The notable new features -- not seen in MetaOCaml (or MetaML, for that
> matter) -- are generating pattern-matching expression with the
> statically unknown number of clauses, and let-insertion as a
> primitive. To wit, |genlet exp| inserts  |let freshname = exp in ...|
> somewhere in the generated code and returns |.<freshname>.| (unless |exp|
> is already syntactically a value such as a variable reference).
> The let-statement is inserted at the most appropriate place.
>
> BER MetaOCaml N104 should be available though OPAM, hopefully soon.
> In the meanwhile, it is available as a set of patches to the
> OCaml 4.04.0 distribution.
>         http://okmij.org/ftp/ML/ber-metaocaml-104.tar.gz
> See the INSTALL document in that archive. You need the source
> distribution of OCaml 4.04.0, see the following URL for details.
>
> For more explanations, please see
>         http://okmij.org/ftp/ML/MetaOCaml.html
> as well as ChangeLog and NOTES.txt in the BER MetaOCaml distribution.
>
>
> --
> 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
>



-- 
Eray Ozkural, PhD. Computer Scientist
Founder, Gok Us Sibernetik Ar&Ge Ltd.
http://groups.yahoo.com/group/ai-philosophy

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

Re: [Caml-list] ANN: BER MetaOCaml N104, for OCaml 4.04.0

[Gabriel Scherer]

For fast just-in-time compilation of OCaml code, you may be interested
in Benedikt Meurer's work on OCamlJit2 (the article is well-written
and easy to read):

  Just-In-Time compilation of OCaml byte-code
  Benedikt Meurer, 2010
  https://arxiv.org/abs/1011.6223

On Mon, Jan 16, 2017 at 2:18 PM, Eray Ozkural <examachine@gmail.com> wrote:
> Hi Oleg,
>
> I have a question. Have you ever designed at length how to implement a super
> fast *interpreted* version of metaocaml, or let me put it this way: do you
> think if that is possible at all?
>
> Best,
>
> Eray
>
> On Sun, Jan 1, 2017 at 6:20 PM, Oleg <oleg@okmij.org> wrote:
>>
>>
>> BER MetaOCaml N104 is a strict superset of OCaml 4.04.0 for ``writing
>> programs that generate programs''.  BER MetaOCaml adds to OCaml the
>> type of code values (denoting ``program code'', or future-stage
>> computations), and two basic constructs to build them:
>> quoting and splicing. The generated code can be printed, stored in a
>> file -- or compiled and linked-back to the running program, thus
>> implementing run-time code optimization. A well-typed BER MetaOCaml
>> program generates only well-scoped and well-typed programs:
>> The generated code shall compile without type errors.
>> Staging-annotation-free BER MetaOCaml is identical to
>> OCaml; BER MetaOCaml can link to any OCaml-compiled library (and
>> vice versa); findlib and other tools can be used with BER MetaOCaml as
>> they are, in their binary form.
>>
>> BER MetaOCaml N104 comes with one minor and two notable improvements.
>> The minor improvement is the availability of the native MetaOCaml.  If
>> the generator is compiled in native mode (using metaocamlopt), the
>> dynamically generated and run code will be natively-compiled as
>> well. The lack of native mode was the most frequently heard criticism
>> of MetaOCaml, although in my experience it hardly even
>> matters. Off-line code specialization seems to be far more prevalent
>> and useful than online one. Anyway, here we have it.
>>
>> The notable new features -- not seen in MetaOCaml (or MetaML, for that
>> matter) -- are generating pattern-matching expression with the
>> statically unknown number of clauses, and let-insertion as a
>> primitive. To wit, |genlet exp| inserts  |let freshname = exp in ...|
>> somewhere in the generated code and returns |.<freshname>.| (unless |exp|
>> is already syntactically a value such as a variable reference).
>> The let-statement is inserted at the most appropriate place.
>>
>> BER MetaOCaml N104 should be available though OPAM, hopefully soon.
>> In the meanwhile, it is available as a set of patches to the
>> OCaml 4.04.0 distribution.
>>         http://okmij.org/ftp/ML/ber-metaocaml-104.tar.gz
>> See the INSTALL document in that archive. You need the source
>> distribution of OCaml 4.04.0, see the following URL for details.
>>
>> For more explanations, please see
>>         http://okmij.org/ftp/ML/MetaOCaml.html
>> as well as ChangeLog and NOTES.txt in the BER MetaOCaml distribution.
>>
>>
>> --
>> 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
>
>
>
>
> --
> Eray Ozkural, PhD. Computer Scientist
> Founder, Gok Us Sibernetik Ar&Ge Ltd.
> http://groups.yahoo.com/group/ai-philosophy

Re: [Caml-list] ANN: BER MetaOCaml N104, for OCaml 4.04.0

[Eray Ozkural]

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

Thank you, that's indeed relevant!

On Mon, Jan 16, 2017 at 4:25 PM, Gabriel Scherer <gabriel.scherer@gmail.com>
wrote:

> For fast just-in-time compilation of OCaml code, you may be interested
> in Benedikt Meurer's work on OCamlJit2 (the article is well-written
> and easy to read):
>
>   Just-In-Time compilation of OCaml byte-code
>   Benedikt Meurer, 2010
>   https://arxiv.org/abs/1011.6223
>
> On Mon, Jan 16, 2017 at 2:18 PM, Eray Ozkural <examachine@gmail.com>
> wrote:
> > Hi Oleg,
> >
> > I have a question. Have you ever designed at length how to implement a
> super
> > fast *interpreted* version of metaocaml, or let me put it this way: do
> you
> > think if that is possible at all?
> >
> > Best,
> >
> > Eray
> >
> > On Sun, Jan 1, 2017 at 6:20 PM, Oleg <oleg@okmij.org> wrote:
> >>
> >>
> >> BER MetaOCaml N104 is a strict superset of OCaml 4.04.0 for ``writing
> >> programs that generate programs''.  BER MetaOCaml adds to OCaml the
> >> type of code values (denoting ``program code'', or future-stage
> >> computations), and two basic constructs to build them:
> >> quoting and splicing. The generated code can be printed, stored in a
> >> file -- or compiled and linked-back to the running program, thus
> >> implementing run-time code optimization. A well-typed BER MetaOCaml
> >> program generates only well-scoped and well-typed programs:
> >> The generated code shall compile without type errors.
> >> Staging-annotation-free BER MetaOCaml is identical to
> >> OCaml; BER MetaOCaml can link to any OCaml-compiled library (and
> >> vice versa); findlib and other tools can be used with BER MetaOCaml as
> >> they are, in their binary form.
> >>
> >> BER MetaOCaml N104 comes with one minor and two notable improvements.
> >> The minor improvement is the availability of the native MetaOCaml.  If
> >> the generator is compiled in native mode (using metaocamlopt), the
> >> dynamically generated and run code will be natively-compiled as
> >> well. The lack of native mode was the most frequently heard criticism
> >> of MetaOCaml, although in my experience it hardly even
> >> matters. Off-line code specialization seems to be far more prevalent
> >> and useful than online one. Anyway, here we have it.
> >>
> >> The notable new features -- not seen in MetaOCaml (or MetaML, for that
> >> matter) -- are generating pattern-matching expression with the
> >> statically unknown number of clauses, and let-insertion as a
> >> primitive. To wit, |genlet exp| inserts  |let freshname = exp in ...|
> >> somewhere in the generated code and returns |.<freshname>.| (unless
> |exp|
> >> is already syntactically a value such as a variable reference).
> >> The let-statement is inserted at the most appropriate place.
> >>
> >> BER MetaOCaml N104 should be available though OPAM, hopefully soon.
> >> In the meanwhile, it is available as a set of patches to the
> >> OCaml 4.04.0 distribution.
> >>         http://okmij.org/ftp/ML/ber-metaocaml-104.tar.gz
> >> See the INSTALL document in that archive. You need the source
> >> distribution of OCaml 4.04.0, see the following URL for details.
> >>
> >> For more explanations, please see
> >>         http://okmij.org/ftp/ML/MetaOCaml.html
> >> as well as ChangeLog and NOTES.txt in the BER MetaOCaml distribution.
> >>
> >>
> >> --
> >> 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
> >
> >
> >
> >
> > --
> > Eray Ozkural, PhD. Computer Scientist
> > Founder, Gok Us Sibernetik Ar&Ge Ltd.
> > http://groups.yahoo.com/group/ai-philosophy
>



-- 
Eray Ozkural, PhD. Computer Scientist
Founder, Gok Us Sibernetik Ar&Ge Ltd.
http://groups.yahoo.com/group/ai-philosophy

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

Re: [Caml-list] ANN: BER MetaOCaml N104, for OCaml 4.04.0

[Oleg]

> Have you ever designed at length how to implement a super fast
> *interpreted* version of metaocaml, or let me put it this way: do you
> think if that is possible at all?

I guess you are asking about the complexity and overhead of building
code representations (because otherwise, MetaOCaml is an ordinary
OCaml program, and could be optimized as such). Code values have a
somewhat complex representation because they also describe all
future-stage free variables that occur within the value. The data
structure used to represent free variable is designed to be
efficient. Long time ago I did a spot test of generating code with 100
free variables. I could not detect any overhead due to the handling of
free variables. Thus in my experience, MetaOCaml-specific overhead is
rather negligible. If there is a real need to get MetaOCaml to generate
code as fast as possible, one should optimize MetaOCaml as any other
OCaml program.

You may also be asking about the performance of Runcode.run.  It
includes compiling the code and running the resulting
bytecode. Compilation does impose overhead. How to reduce it is a
complex question. For now I remark that the generated code is usually
rather simple. One could compile it with rather old version of OCaml,
which was really fast.

        Cheers,
        Oleg

Re: [Caml-list] ANN: BER MetaOCaml N104, for OCaml 4.04.0

[Eray Ozkural]

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

On Thu, Jan 19, 2017 at 12:20 AM, Oleg <oleg@okmij.org> wrote:

>
> > Have you ever designed at length how to implement a super fast
> > *interpreted* version of metaocaml, or let me put it this way: do you
> > think if that is possible at all?
>
> I guess you are asking about the complexity and overhead of building
> code representations (because otherwise, MetaOCaml is an ordinary
> OCaml program, and could be optimized as such). Code values have a
> somewhat complex representation because they also describe all
> future-stage free variables that occur within the value. The data
> structure used to represent free variable is designed to be
> efficient. Long time ago I did a spot test of generating code with 100
> free variables. I could not detect any overhead due to the handling of
> free variables. Thus in my experience, MetaOCaml-specific overhead is
> rather negligible. If there is a real need to get MetaOCaml to generate
> code as fast as possible, one should optimize MetaOCaml as any other
> OCaml program.


Yes, I might also be asking about the complexity of designing an extremely
fast / ideal runtime system. [Ocaml's bytecode and interpreter is nice, but
it is not quite what I would do. Anyhow, that's off-topic.]

I'm glad to hear there isn't major overhead with free variables, that would
be a potential bottleneck. That's quite nice and encouraging.

>
> You may also be asking about the performance of Runcode.run.  It
> includes compiling the code and running the resulting
> bytecode. Compilation does impose overhead. How to reduce it is a
> complex question. For now I remark that the generated code is usually
> rather simple. One could compile it with rather old version of OCaml,
> which was really fast.
>

I did think at length on how to do that with code generated on the fly. It
seemed like there is some unavoidable costs associated with the usual, like
type-checking of course. I had considered metaocaml for my AGI codebase
once, now I will think again, thanks for your remarks. My code is written
in ocaml, so I do try to evaluate every significant ocaml technology
developed. Let's stay at the cutting edge, and many thanks for your awesome
contributions again!

https://github.com/metaocaml/ber-metaocaml/blob/ber-n104/metalib/runcode.ml

Celebrating Oleg's cyber poetry here ^_^

Best,

-- 
Eray Ozkural, PhD. Computer Scientist
Founder, Gok Us Sibernetik Ar&Ge Ltd.
http://groups.yahoo.com/group/ai-philosophy

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