Hm, wouldn't the obvious answer to this problem be to implement a layer of macro expansion between the reader and the current macro-expansion phase, that did macro-expansion for special kind of macros that worked just like normal macros, but that expanded parameters to a m acro before expanding the macro itself? Such a layer could be very simple, separate from the infix-package and usable for many other purposes. _But_, I'm not sure the problem even exists. What kind of macros do you envision that would like to peek inside its parameters, and would have problems with a parameter being (nfs foo bar fie) instead of (bar foo fie)? Most macros treat their arguments as opaque and just inserts them in various places inside a pre-written body of code. The best example of this is the let-macro: (let ((a (nfx foo bar fie))) (+ a 3)) expands to ((lambda (a) (+ a 3)) (nfx foo bar fie)). /Egil --
Konsulent, Fri Programvare / Free Software Consultant |
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ Readable-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/readable-discuss
