(Note: Please make sure you reply to the GROUP, not just the From: address....!).
I noted earlier: > > The problem with infix macros is that any OTHER macro that is invoked BEFORE > > the infix macro will necessarily see the WRONG operators. So, for example, > > a > > macro that looks for (* ... (+ ....) ....) and replaces it with something > > else will NOT > > see the "+" if it's invoked in a context before the substitutions occur. > > This means that just when you start depending on the macro, it "breaks". Alan Manuel Gloria replied: > Generally, if I *do* have to write a macro that replaces a particular > sub s-expression, I do (macro-expand body) first, because of this > possibility. However, this approach can be broken if the form I'm > finding is ever implemented as a macro (e.g. if (+ ...) is a macro > form and I need to search for that form). Right. That's the basic problem with the infix macros; they work really well in many cases, but in some other cases they don't. Which is why I think that both macro and reader-based approaches have their places. But I'm especially interested in the reader-based approaches, because they work everywhere without issue. If they can then hook into the macro-based approaches, when appropriate, that seems like the best of all worlds. (regarding array access notation): > How about a[x][y] instead? Understandably it requires that your > multi-dimension data structure to be decomposable into fewer-dimension > ones, but even if that is difficult, you could model a[x] on a > two-dimensional a[x][y] structure as equivalent to a curried > bracketaccess function. I would argue that an a[x][y] syntax would be > simpler than a[(x) (y)], especially if you want to support ranges and > stepped ranges. Hmm, that's certainly true. a[x][y] is actually pretty nice syntactically; it's not as nice for the simple case of accessing element x,y - but it's obviously easy to expand each one. Supporting that actually comes "for free" in my current reader definition, though I hadn't considered using it that way. But that requires that the "bracketaccess" macro (or whatever) handle that. I wonder if the "reaching in" of that macro will cause unhappy surprises. Anyone interested in trying to implement at "bracketaccess" macro to actually try out some options? In the end, only experimentation can determine if that makes sense, or if it doesn't. --- 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
