On Feb 4, 2008 11:52 AM, David A. Wheeler <[EMAIL PROTECTED]> wrote:
> (Note: Please make sure you reply to the GROUP, not just the From:
> address....!).
Dang. I keep forgetting.
>
> 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.
However, having a rule about whether it ends up hooking into a macro
will then mean having an additional rule that has to be remembered by
the user of the new reader, as well as possibly the user of any macro
that has to do scanning of that type. So I propose that either the
reader completely handles infix, or it completely ignores it - no
in-between.
As an aside, at the office we are using a Lisplike with an infix
notation, however I tend to avoid the infix notation except at repl.
For coding, I use Lisp syntax almost completely, especially after I
finally "got" macros.
>
> (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.
If there is some way of determining the number of dimensions, then it
should be easy.
#|Assumes existing functions:
(bracketaccess-generic obj &rest dimensions)
- accesses a dimensioned object; the number of dimensions
given must match the number of dimensions in the actual object
(get-number-of-dimensions obj)
- determines the number of dimensions in the obj
|#
(define (bracketaccess o d)
(cond
( (listp o)
(if (eq (get-number-of-dimensions (car o)) (length o))
(apply #'bracketaccess-generic (append o (list d)))
(append o (list d)) ))
( (neq 1 (get-number-of-dimensions obj))
(list o d) )
( t
(bracketaccess-generic o d) )))
#|Creating a congruent setf-macro is left as an exercise to the reader|#
In the above untested sample, the bracketaccess function never
actually "reaches in" the object except at the final bracketaccess;
however, it does require two additional methods and can't be used to
bracketaccess a list (although we could use a non-ordinal data
structure instead, say a defstruct; this is just a proof-of-concept).
The list that the function sometimes returns represents the curried
bracketaccess. I suspect bracketaccess-generic and
get-number-of-dimensions can be implemented in the CLOS; but being a
complete ignoramus on that, I can only suspect.
>
>
> --- 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
>
-------------------------------------------------------------------------
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
