Title: FreeCode Signature
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.
This is generally the main reason why I kept suggesting adding a tag
for all infix, and why I kept suggesting that infix should not be
default. David's main concern is that other macros will see the 'nfx
macro:
(defmacro my-macro ....)
my-macro {juan + juan}
=> my-macro ends up seeing (nfx juan + juan) instead of (+ juan juan)
Isn't that a feature rather than a bug? In
my-macro '(foo bar)
my-macro sees (quote (foo bar)), rather than the list (foo bar).
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...)
I don't quite understand this, is this an implementation detail or
will this be embedded into the input list?
Just an implementation detail, that allows a generic nfx-macro to be
created once and for all, that could handle any operators.
--
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
