This now works:
///////////////////////////////////
#import <flx.flxh>

syntax extension {
  sexpr := sexpr "over" sexpr =># (_1 / _3);
}

open syntax extension;

var x = 100 over 20;
println x;
/////////////////////////////////

The user action is a **currently parseable** Felix expression
written in parentheses, instead of a Scheme string. 
That means, you cannot use 'just defined' syntax in the action,
the syntax must have been opened already.

The production must only involve nonterminals of which result
in Felix terms of expression kind, although any nonterminal
of that kind can be used, **even if** the nonterminal is not
referred to in the user action.

The latter constraint is quite onerous, I might fix it.
The reason is explained below in a more general setting.

The way this works is to use the macro processor term
substitution capability. That requires each term to be
known as either an expression, statement, list of statements,
identifier, or keyword.

There is one more term kind: term application. This is some
term containing _1, _2, etc etc, plus a list of terms.
The macro processor replaces the _1, _2 etc with the corresponding
term from the list.

This is roughly equivalent to how it is done in Scheme, except
in Scheme all the terms just has type 'sval' -- Scheme value.
In the macro processor we're working with Felix AST terms,
and the AST_term_t union only handles a few cases (as listed
above). It doesn't handle patterns, for example.

So the problem is that the sex2flx converter actually has
to translate Scheme representations like 

        "(Expression_term e)"

into Felix AST terms like

        `Expression_term e'

where e' is actually value of type expr_t .. SO .. the svalue
really has to convert to an expression. So you cannot write:

        sexpr := lpar sexpr "over" sexpr rpar =># ( _2 / _4 );

because, even though _1 and _5 are not used in the user action,
they're still converted to Felix expressions .. and that
conversion will fail because lpar happens to be a nonterminal
returning Snull Scheme value, which isn't a valid Felix expression.

I can fix this by simply replacing errors with a dummy value,
and that's fine if they're not used .. but will be hard to debug
if it happens to be one of the used nonterminals that really should
have been an expression.

For user defined statements, there's a related problem: we have
no idea which nonterminals are what kind.

Another REALLY hacky solution is just trial and error.. try
to handle a term as a statements, statement, and expression,
and see which one doesn't barf... 



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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language

Reply via email to