I said: > Actually, that IS what I'm doing. By doing the transformation at read-time, I > do the transformation BEFORE any macros run.
Egil Möller replied: > 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 macro before expanding the > macro itself? Such a layer could be very simple, separate from the > infix-package and usable for many other purposes. That would be another way to solve the problem. But since macro-expansion is typically "built in" to Lisps in their define etc. statements, I would need to override their definitions. Some Lisps (like Common Lisp) are decidedly unfriendly about overriding basics like that. For Scheme I have a different problem: every Scheme implementation is radically different and have incompatible extensions, none of which would work if I overrode some things (because I wouldn't correctly override EVERYTHING). It's also a sledgehammer approach. Having _two_ macro phases would slow down processing, as well as requiring a lot of work, and it also complicates the mental model. There are already two phases (read, and macro-processing)... I'd hate to add a third unless there's a CLEAR need. > _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)). They happen all the time in code optimization and checking. Indeed, Scheme's macro processing language is specially designed for non-simple pattern-matching, which you don't really need unless you're basing decisions on what's INSIDE. Many processors (including x86) have special instructions that you'd like to detect and take advantage of, for example. And often certain operators can't be combined with others in certain ways... so you need to detect that too. All of which doesn't work if you can no longer guarantee that the first parameter is the operator. --- David A. Wheeler ------------------------------------------------------------------------- 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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
