Version française
Home     About     Download     Resources     Contact us    
Browse thread
camlp5/revised syntax questions
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Aaron Bohannon <bohannon@c...>
Subject: Re: [Caml-list] camlp5/revised syntax questions
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