Re: [Scheme-reports] auxiliary syntax

[Peter Bex <Peter.Bex@x>]

On Sun, Jan 06, 2013 at 12:37:18PM -0500, John Cowan wrote:
> Peter Bex scripsit:
> > I think trying to catch these things is misguided.  It's fine if an
> > implementation like Racket does this to guide students, but seasoned
> > Scheme programmers don't need this kind of hand-holding.
> 
> On the contrary.  The whole point of binding them by default is so that
> they can safely be rebound and used as auxiliary keywords by other macros.
> If they are left unbound, they are inherently non-hygienic.

Isn't that by definition the case with aux-keywords in syntax-rules?
Adding them to the default environment for this reason seems rather
contrived, unless you go all the way and remove aux-keywords from
syntax-rules altogether.  You can't have your pie and eat it too.

Also, I'm not sure if this is R5RS-compatible.  The second form in the
following returns 1 in Chibi, Chicken, Gambit, MIT Scheme and Gauche:

(define else #f)
(cond (else 1))

Racket, Guile and Scheme48 seem to agree that it's an unspecified value.
The define-syntax variant produces the same result except in MIT Scheme
where it results in a "syntactic keyword may not be used as an
expression" error, which seems equally incompatible to the R7RS notion
of providing default syntax forms for these keywords.  In Scheme48 it
also causes an "invalid variable reference" error.

The R7RS shouldn't introduce incompatibilities with R5RS, but I'm unsure
whether the above behavior is strictly speaking a bug, simply undefined
in R5RS or really on spec.

> If only syntax-parameters were a little more mature, I'd
> propose them for R7RS-large like a shot: they are the best
> resolution I have seen to the desire to break hygiene.  See
> <http://docs.racket-lang.org/reference/stxparam.html> for Racket,
> <http://www.gnu.org/software/guile/manual/html_node/Syntax-Parameters.html>
> for Guile, and the paper
> <http://www.schemeworkshop.org/2011/papers/Barzilay2011.pdf>.
> In particular, it would be good to know if syntactic-closures and
> explicit-renaming systems allow them easily.

This looks interesting, but will require some more experimentation
before being generally acceptable, I think.  I'm wary of things like
this, as it seems a lot like the unholy idea that all DSSSL-style
keywords must be bound.

Cheers,
Peter
-- 
http://sjamaan.ath.cx

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