|
I was thinking about the {}-infix notation and implementation, and
realized a rather sad side-effect - the actual parse-tree, what is fed
to eval, does not resemble the input any longer, as it does for all
other syntax sugar (quoting and so on). My suggestion is to simplify the reader-macro, so that it only rewrites {1 * 2 + 4 * {5 + 6}} into (nfx 1 * 2 + 4 (nfx 5 + 6)) and do the rest with an ordinary macro, nfx. I guess that that would also be easier to extend, and generally to work with. Also, it would be easy to add a printing hook that rewrites anything (nfx ...) into {...}, just like it works for quotes. One way to handle operator precedence would be to call a special function for each pair of used operators: {1 * 2 + 4 * {5 + 6}} (precedence_*_+ 1 2 4) -> * (precedence_+_* 2 4 11) -> * (note the parameters, to be able to use the types to differentiate operators, don't know if that is really needed thou...) This way, it would be easy to extend the set of allowed operators. /Egil -- Konsulent, Fri Programvare / Free Software Consultant Cell: +47 - 91 17 05 93 Phone: +47 - 21 53 69 00, Fax: +47 - 21 53 69 09 Addr: Slemdalsveien 70, PB 1 Vinderen, 0319 Oslo  Free beer costs nothing, freedom costs a fight. Free beer lasts an eavening, freedom lasts a lifetime. |
signature.asc
Description: OpenPGP digital signature
