From: Gabriel Scherer <gabriel.scherer@gmail.com>
To: Oleg <oleg@okmij.org>, caml users <caml-list@inria.fr>
Subject: Re: [Caml-list] ANN: BER MetaOCaml N104, for OCaml 4.04.0
Date: Sun, 1 Jan 2017 11:03:56 -0500 [thread overview]
Message-ID: <CAPFanBFt1Yjp8xERmLx7FKv8rOzdUMy+7DQ3sYbzo3y1ESa30g@mail.gmail.com> (raw)
In-Reply-To: <20170101152022.GA1291@Magus.localnet>
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
next prev parent reply other threads:[~2017-01-01 16:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-01 15:20 Oleg
2017-01-01 16:03 ` Gabriel Scherer [this message]
2017-01-01 19:25 ` Manfred Lotz
2017-01-01 19:34 ` Gabriel Scherer
2017-01-01 20:06 ` Manfred Lotz
2017-01-15 8:55 ` Oleg
2017-01-14 12:10 ` Eray Ozkural
2017-01-16 13:18 ` Eray Ozkural
2017-01-16 13:25 ` Gabriel Scherer
2017-01-16 17:12 ` Eray Ozkural
2017-01-18 21:20 ` Oleg
2017-01-20 3:13 ` Eray Ozkural
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPFanBFt1Yjp8xERmLx7FKv8rOzdUMy+7DQ3sYbzo3y1ESa30g@mail.gmail.com \
--to=gabriel.scherer@gmail.com \
--cc=caml-list@inria.fr \
--cc=oleg@okmij.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox