At Thu, 25 Mar 2004 12:55:10 -0800 (PST), xxxxxx@autodrip.bloodandcoffee.net wrote:
>
> On Wed, 24 Mar 2004, Alex Shinn wrote:
>
> > Since we need to define define-syntax-computation separately in this
> > SRFI for portability, why not make it the more readable version?
>
> I'd rather lose that portability element, since it already is quite
> portable _anyways_ to define a SYNTAX-COMPUTATIONS (or whatever it ends
> up being called) macro that can work just fine in syntax definition
> right-hand-sides, even if that is non-standard; that way DEFINE-SYNTAX
> does not lose its universal status as the introducer of derived syntax
> and only a little bit of portability is lost.

In many Schemes DEFINE-SYNTAX is a low level primitive that specifically
does not expand the inside as a macro, so this simply isn't an option if
you want portability.  If the author chooses to forgo portability and
not use DEFINE-SYNTAX-COMPUTATIONS, then the point becomes moot.

[I do prefer SYNTAX-COMPUTATIONS though.]

> I really don't think the extremely minor element of brevity here makes
> any difference at all.

This has nothing to do with brevity, but with removing warts and
improving readability and learnability.  Newbies run in terror when they
see define-syntax.  The following is easier to read and to teach

  (define-syntax-computations and ()
    () #f
    (x) x
    (x y z ...) (if x (and y z ...) #f))

than

  (define-syntax and
    (syntax-rules ()
      (() #f)
      ((x) x)
      ((x y z ...) (if x (and y z ...) #f))))

It took me a while of using SYNTAX-RULES before I could remember the
current syntax.  It would have helped if I had learned first that the
DEFINE-SYNTAX just registers a macro, whereas SYNTAX-RULES is one of
many ways to actually create the macro, but this is not a reality in
most Schemes, and not likely to become one anytime soon because it
presumes first class environments (preferably with SYNTAX-CLOSURES as
the base system).

As an aside, it seems whenever someone makes a suggestion that would
shorten the resulting Scheme code they get attacked for wanting
"brevity" *shudder*.  Somehow such practical considerations are viewed
as taboo because they don't have any obvious theoretical value.  But
there is value in removing noise and keeping the language pure, which is
why there is no THEN in IF statements.  Given
DEFINE-SYNTAX-COMPUTATIONS, nesting a SYNTAX-COMPUTATIONS is just noise.

--
Alex