7 hours ago, Alaric Snell-Pym wrote:
> Aye, that's one thing I don't like about the "syntax-case macro
> system" as a whole; it tries to steal the top slot! [...]

It makes perfect sense for the system to steal that top slot.

First, it goes with the overly abused and worn-out "jewel like" point.
A syntax trasnformer is something that ... transforms syntax, so a
natural type for it is `Syntax -> Syntax'.  It is this property that
makes it an appealing system in many cases -- it's simple enough that
I can even talk about it in an undergrad class.  The type is easy for
students to comprehend, and I can show examples like:

  > ((syntax-rules () [(_ x y) (blah y x)]) #'(foo x y))
  #<syntax::43 (blah y x)>
  > ((syntax-rules () [(_ x y) x]) #'(foo x y))
  #<syntax::92 x>               ; <--- (look ma, no hands!)

Second, consider the high-level approach to macros: with a syntax case
system the general approach is -- extend the type of "syntax" to
accommodate more needs.  This means that these systems are committed
to this `Syntax -> Syntax' type, and if there are any extensions for
the system that are needed, then they are achieved by extending the
notion of "Syntax".

On the other hand, something like ER takes the opposite approach: the
commitment is to keep the "syntax" as plain sexprs.  (A bad illusion,
IMO, but that's irrelevant.)  To make this possible, the system bends
over backwards and uses a *much* more complicated type to deal with
transformers -- either extra input functions, or some representations
of environments.  I know that it's not *that* complicated, but think
about teaching it in a similar course: students are completely baffled
by the whole idea of doing syntax transformations, and the last thing
they need at that point is more noise in the form of dealing with a
higher order function type or some notion of environment.  Further, it
breaks the nice uniformity that the above interaction example
demonstrates: Scheme is overall a simple language, so IMO explaining
`syntax-rules' as something that evaluates to a `Syntax -> Syntax'
function is a far better option when compared to one of these types.

And there's a second point on this side of the fence too: since the
commitment is fundamentally different, possible extensions to the
macro system are likely to break the N argument that an ER macro
transformer uses.  In fact, if you look around (see that old post that
Alex wrote which I referred to recently), you'll see functions with a
sexpr and one environment, two environments, a rename function, or a
rename and a compare function.  Also, consider that Alex recently
wrote:

| Most SC based systems take three parameters, and I've toyed with the
| idea of four or five.

Do you see how brittle the function signature is?  With this approach
it is natural to require a wrapper function or form for the actual
transformer function, since the function's signature is likely to
change.  My guess is that this is exactly why these wrappers are
common in ER/SC systems -- whereas the syntax case approach assumes a
fixed simple `Syntax -> Syntax' and goes from there.

Here's a more concrete way to rephrase this high-level point: this
thread began with Andy writing:

| I would like to argue in favor of single-arity, single-return syntax
| transformers.

and given that he's using a syntax case system it's obvious that he
really wants just that.  On the other hand, Alex replied with

| I would like to argue in favor of triple-arity, single-return syntax
| transformers.

which he obviously didn't mean seriously, since it was just a few days
ago that he contemplated "four or five" arguments.

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

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports