I have introduced a new statement and modified some behaviour
as follows.

The statement like:

SCHEME "scheme code here";

can be used to execute scheme code for side-effects. 
The resulting value, if any, isn't used. This is used
in the nugram.flxh file, which contains the statement:

SCHEME """
(define fold_left
  (lambda (f acc lst) 
    (if (null? lst) acc (fold_left f (f acc (car lst)) (cdr lst)))))
""";

Later on, the definition of fold_left is used like:

    selse_part:= selifs else sexpr =># """
       (let ((f (lambda (result condthn) 
         (let ((cond (car condthn)) (thn (cadr condthn))) 
           `(ast_cond (,cond ,thn ,result))))))
         (fold_left f _3 _1))
    """;
/*    
    selse_part:= selifs else sexpr =># """
     (letrec 
       ((fold_left 
         (lambda (f acc lst) 
           (if (null? lst) acc (fold_left f (f acc (car lst)) (cdr
lst))))))
       (let ((f (lambda (result condthn) 
         (let ((cond (car condthn)) (thn (cadr condthn))) 
           `(ast_cond (,cond ,thn ,result))))))
         (fold_left f _3 _1)))
    """;
*/

where the new definition used fold_left, whereas the old,
comment out one, defined it in place.

The behaviour of the parser is now changed though.
It uses local_data instead of global_data.

This means, for example, you can extend or define a DSSL
inside a module, but it will not be available after the module
is closed. That is, dssl *definitions* respect scope now.
Previously, they were global, although opening a definition
respected scope.

This also applies to SCHEME statements. For example this works:

//module X {
SCHEME "(define pi 42)";
//}

SCHEME "(+ 100 1000 pi)";

but if you remove the comments, then the definition of pi
is scoped inside the module X body by the parser,
and the sum fails because the variable 'pi' is undefined.

It is rather unfortunate that Scheme is imperative with
mutable variables. To *prevent* environment extensions
leaking out of scopes, the implementation actually
copies the environment before evaluating the SCHEME term.
Afterwards, the current environment stored in dyp.local_data 
is set to the  modified environment. This way, the modification
only propagates within the current scope.

I note this will probably NOT work if the variable is bound to
some mutable data structure such as a scheme Vector, since
copying the environment probably doesn't copy the values
variables are bound to (but I'm not sure :)

The only other way to do this I can think of is store up
the strings in an Ocaml list, and execute the list in
reverse on every reduction .. ;(

Note: the Felix grammar is rather long winded,
and some of the Ocaml user actions quite complicated.
I'm playing with Dypgen and extension features some of the
time to relieve the boredom of rewriting the grammar ..
it will get finished sometime soon :)

Note2: one thing I didn't mention before: the nu grammar
does not propagate source references at the moment.
That is yet to be done.. I hope to compute them with
a universal calculation on the matched token stream.
[in the old grammar, I have to write code to calculate
the source reference in every user action ..]

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language

Reply via email to