Version française
Home     About     Download     Resources     Contact us    
Browse thread
augmented camlp4 ASTs
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jeff Henrikson <jehenrik@y...>
Subject: augmented camlp4 ASTs
Hello,

Trying to measure the feasibility/cost of doing a couple of things with 
camlp4.  I like the camlp4 capability of adding constructions to the 
grammar.  However, I sometimes want to do nonlocal transformations on 
the contents, and the fact that I always must immediately return an 
expression on the right hand side bothers me.  I can call the parsing 
part of camlp4 to get an MLast.expr, but the MLast grammar is fixed and 
cannot have productions added to it.  One way to get an extensible 
grammar would be to project one-to-one into (not onto) a looser AST 
type, something like:

type delimiter = char * char

type separator = char

type sexp =
  Atom of string
| Series of delimiter * separator * sexp array
| SpecialForm of string * sexp array * sexp array;;

(I haven't handled everything here, like infix operators.)

Then all the quotations of MLast.expr could be rewritten to target this 
grammar, and the parser could be copied to write into these 
expressions.  When future EXTEND statements add things, the 
corresponding entries in the AST could be added.

The downside is obviously that our exhaustiveness checking is defeated.  
Always the price one pays for dynamicism.

Something new and different which would be possible if an alternate AST 
like this were substituted is the creation of a "universal" indentation 
mode, which would indent any traditional syntax, revised syntax, or any 
extensions thereof.  Preferences would be reduced to a lookup table 
which mapped special forms to their indentation.

  "if" => +2
  "let" => +2
  "in" => -2

(there would probably have to be more context here)

As for my use case of nonlocal macro transformations, the low road is of 
course to project my special forms into "reserved" identifiers which 
look like values but are actually still special forms.  I run my 
transformations with special cases to catch my transformed special 
forms.  This is not horrible for the use case I have in mind now.

Thanks for any help.

Regards,


Jeff Henrikson