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