caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Aaron Bohannon <bohannon@cis.upenn.edu>
To: blue storm <bluestorm.dylc@gmail.com>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] camlp5/revised syntax questions
Date: Tue, 13 Oct 2009 22:04:11 -0400	[thread overview]
Message-ID: <c413fcb70910131904x7f506d9hd45f13de15c49536@mail.gmail.com> (raw)
In-Reply-To: <527cf6bc0910100531w2ee13210w2351e99adb4761ec@mail.gmail.com>

On Sat, Oct 10, 2009 at 8:31 AM, blue storm <bluestorm.dylc@gmail.com> wrote:
> The revised and classical syntax are designed as syntax extensions
> (pa_o.ml pa_r.ml) that extend an empty grammar, wich already contains
> some (empty) grammar entries. They first clear every entry of that
> grammar (probably to make sure it's really empty), then add by
> extension every syntaxic construct of the ocaml language. They get
> compiled to pa_o.cmo and pa_r.cmo, wich you can pass to camlp4 to
> choose one of the two syntax :
>  camlp4 pa_o.cmo my_extension.cmo ...
>
> What happens here is that :
>  - camlp4 starts with an empty ocaml grammar
>  - you link it to pa_o.cmo, wich gets executed and set up the
> classical syntax (by mutation of the (empty) grammar entries)
>  - you then add your own extension wich makes additional mutations

Ah.  I didn't understand that you can (and must) compile syntax
extensions without committing to which grammar you are extending.
Sequencing the "cmo" files as arguments to "camlp4/5" makes enough
sense.  Things seem a little more magical when loading extensions with
the "#load" directive because it seems the parser has to change its
behavior while it's in the middle of parsing, but at least I've got
the basic idea now.

> I'm not sure what you mean here, but I'm under the impression that
> you're confusing the syntaxic representation of the expression and its
> runtime/compile-time semantic. Camlp* knows nothing of the meaning of
> the code it produces; the output is an AST wich has no idea of what a
> "reference" and a "value" means. The semantic of the given code
> depends on the deeper passes of the compiler (for example typing),
> wich probably have an internal language of their own, and surely make
> the difference between lvalue and rvalues.

OK.  I wasn't very precise.  I meant that, with those parsing rules,
there must be a sort of error that is generated after parsing, but
before type-checking.  For instance,  let's say we have

    type foo = { mutable bar : int; }

Then, according to the grammar, there is no parse error in the expression

    { bar = 3 } . "bar"

But I don't know of what OCaml type error this is supposed to generate
either.  And as I wrote this, I realized it's quite easy to try this
out and see what happens.  What we actually get (using camlp5o) is:

    Failure: lowercase identifier expected

Similarly, you can try this expression

    "foo" <- 3

and you will get

    Failure: bad left part of assignment

I guess that, in practical terms, these are just parse errors, too.
However, they are still a bit mysterious since they get generated on
expressions that conform to the grammar.  Poking around the camlp5
sources, it appears the errors are generated by camlp5, which means
these expressions probably do not represent valid OCaml ASTs.  In that
case, I find camlp5's grammar design a little puzzling.

 - Aaron


      reply	other threads:[~2009-10-14  2:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-07 16:20 Aaron Bohannon
2009-10-07 20:16 ` [Caml-list] " blue storm
2009-10-08 14:39   ` Aaron Bohannon
2009-10-10 12:31     ` blue storm
2009-10-14  2:04       ` Aaron Bohannon [this message]

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=c413fcb70910131904x7f506d9hd45f13de15c49536@mail.gmail.com \
    --to=bohannon@cis.upenn.edu \
    --cc=bluestorm.dylc@gmail.com \
    --cc=caml-list@yquem.inria.fr \
    /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;
as well as URLs for NNTP newsgroup(s).