[racket] Expander vs Reader layer and general Macro advice

A few minutes ago, Ryan Culpepper wrote:
> On 09/09/2013 10:06 AM, Eli Barzilay wrote:
> > An hour ago, Jay McCarthy wrote:
> >> You can do this a complicated way and an easy way. The complicated
> >> way would have to deal with stuff like (f 1):5 and the easy way
> >> would just work on stuff like x:1. I see "string":e as being part of
> >> the complicated way. In my mind, the complicated way would have to
> >> be done with a reader that produced some syntax that the expander
> >> dealt with the rest of. The easy way would just be a #%top macro
> >> like you have.
> >
> > There's a much easier way: use the built-in reader, then scan the
> > resulting syntax tree and tweak occurrences of `? : ?'.  This of
> > course requires spaces around all `:'s -- but dealing with that should
> > be simple now: change the default reader table to make `:' a
> > terminating reader macro, and make it consume just the colon and
> > produce itself as an identifier for the previous hack to continue
> > working.
> 
> What does
> 
>    (a b #; c:d e)
> 
> read as?

Obviously, with just the simple first hack you get something different
than the one with the slightly more complicated reader extension.


> Adding an infix S-expression syntax means that you now have to worry
> about its precedence relative to all of the prefix syntaxes.

Exactly.  (And the lack of real precedence in the sexpr syntax
complicates things since you usually don't get a choice, unless you
are going with a whole new reader.)


> (Maybe that's what you meant to point out below, but the example should 
> be 'x:y, not '(x:y), I believe.)

Not really, I was pointing at the simpler problem of the kind of
post-reader processing that I talked about -- if you do some "manual"
conversion of x : y to (cons x y), then you get nasty surprises when
you have that inside a quoted context.  This was actually one of the
major problems with designing the @-syntax, which is handled nicely by
making nested @s mean the same as they are on the outside.

The 'x:y problem is arguably tricker (though perhaps less subtle) and
is the same issue as in the @;x:y case.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!