[Chicken-hackers] [PATCH] Add support for R7RS syntax-rules extensions

[Peter Bex]

Hi all,

An important part of getting R7RS-small support into Chicken is
extending a few things in core.

Here's a patch to add the new extensions for syntax-rules.  The first
is the ability to "disable" the special meaning of ellipsis in template
forms by starting a list subform with an ellipsis identifier, like

(syntax-rules () ((bla foo bar) (mooh (... ...))))
This will not give an error, but literally expand to (mooh ...).
This also works nested, like in (mooh (... (blabla haha ... hello)))

The second is a bit silly and strictly speaking it breaks backwards
compatibility: the underscore character has a special "wildcard"
meaning in R7RS syntax-rules.  This means it will match anything
and will just expand to a literal underscore in templates:

(syntax-rules () ((bla _) (mooh _))) will literally expand to (mooh _),
not to the second expression in a call to this macro.  I think this
happens so rarely this is not worth going through a Change Request
for this.  If you disagree, please say so.

Strictly speaking, "extended" syntax-rules could be provided as part
of an R7RS egg, but it makes more sense to add it to core, since it's
just a small tweak and it improves compatibility with other Schemes
which already support these extensions (like R6RS Schemes, and pre-R6RS
Racket and Chez Scheme).

The ellipsis patch works by simply threading the ellipsis? predicate
all the way through all the calls, and switching to (constantly #f)
for processing REST when it sees (... . REST).  I initially used a
fluid-let to do the switch, but then decided against it, as the explicit
passing of el? is cleaner and easier to understand, IMHO.

The underscores patch simply skips over _ in the input pattern
(ie, in process-pattern) and generates no matching code for it (since it
won't be visible in a bound pattern variable), just like it does for
elements of the keyword literals list (which are also only used for
matching).  While looking for meta-variables, it will simply not add
the underscore to the pattern variable list.  Finally, there's no
special handling in the expansion itself.  Because _ does not get
added to the meta-variables, it won't recognise them in your templates,
so it'll just get expanded to a free variable named _.

The patch also cleans up the syntax-rules implementation a little by
removing unused aliased names and using %syntax-error instead of the full
##sys#syntax-error-hook name.

Finally, these extensions appear to introduce some ambiguities when
combined.  I've sent a mail to scheme-reports about this:
http://lists.scheme-reports.org/pipermail/scheme-reports/2013-May/003499.html
I didn't get any satisfactory replies so far, so I guess these
ambiguities are just an unspecified corner in the R7RS document.
R6RS (of course) nails this down and explicitly states "It is a syntax
violation if an ellipsis or underscore appears in (<literal> ...)".
I've decided to just leave it semi-specified and not try to bend over
backwards to detect this "error" situation, instead just falling back
to do the "obvious" thing, which in the code is to just let the
ellipsis escape take precedence over literal keywords, and to let
ellipsis specifier take precedence over underscore wildcards.
I've added tests to prevent regression later when people start
inadvertently relying on this.

Cheers,
Peter
-- 
http://www.more-magic.net

0001-syntax-rules-R7RS-compatibility-Implement-ellipsis-e.patch
Description: Text document

0002-syntax-rules-R7RS-compatibility-Implement-underscore.patch
Description: Text document

0003-Add-syntax-changes-to-NEWS.patch
Description: Text document