Re: How many arguments to a macro transformer?

[Keith Wright <kwright@xxxxxxxxxxxxxxxxxx>]

> From: Andre van Tonder <andre@xxxxxxxxxxxxxxxxxxx>
> 
>  No, it is broken on purpose.  The model changed a little from the
>  previous version.
>    
>  One could still make QUASISYNTAX macro-expressible by 
>  introducing a form, maybe called WITH-SINGLE-RENAMING-FUNCTION
>  (the opposite to WITH-FRESH-RENAMING-SCOPE of the previous version)
>  that overrides this default in the obvious way,
>   
>  I considered addihg such a form, but then realized that it is the
>  same as the trivial combination (quasisyntax (unquote ...)), i.e.,
>    
>  so one might as well introduce quasisyntax from the beginning and
>  avoid polluting the namespace with an extra form that would never be
>  used except for implementing quasisyntax.

I read this with a sinking heart, thinking of arguments to prove
that we need |quasisyntax| to be expressible purely in terms of
|car|, |cdr|, |cons| and two symmetric scope/rename forms.

But I thought for a few minutes and realized you had already
thought of my arguments and gone one better.  This feels like
an impovement now that I have had a chance to get used to it.

>  (An advantage of the current choice is that
>  with-fresh-renaming-scope is no longer necessary and has been
>  dropped).

So symmetry is preserved by dumping both halves!  Sweet!

Since we need to have some primitive scoping forms, they might
as well be built into |quasisyntax| where they won't be obtrusive.
It now seems obvious that #`(...) must do some things that are not
just the same as `(...) or we wouldn't need both of them.  They
are similar enough to give helpful analogies, but not redundant.

This revision is more than a trival change.  It seems to me
that it would be a good idea to extend the discussion period
to give more time to think about it.  Don't let it go into
final status before it is noticed, understood, and polished.
We have waited ten years for the One True Macro System,
it would be a shame to rush the last two months and then
discover after it is finalized that something was overlooked.

I would particularly like it if some gurus familiar with the
various implementations would comment on whether there is
anything in the SRFI that conflicts with their diverse macro
systems.

KW > The appendix of R4RS says that it has been suggested
KW > (it doesn't say by whom) that #'<datum> and #`<datum>
KW > would be felicitous abbreviations for (syntax <datum>)
KW > and (quasisyntax <datum>).  Could this be added to the
KW > SRFI?

It has come to my attention that MzScheme already does this.
Macrology has been much elaborated while I was not paying
attention.  Elaborated, but not clearly advanced.

MzScheme also has two procedures called |datum->syntax-object|
and |syntax-object->datum|.  These conflict with your newly
renamed  |datum->syntax| and |syntax->datum|.  I don't know
why you changed the names, but it is a conflict, not a
compatibility, because the MzScheme syntax objects are not
lists and can not be accessed with |car| and |cdr|.

It seems unlikely that programs written to work with the
MzScheme system that used these procedures could run unchanged
on the SRFI system or vice-versa---the data types are completely
different!

To avoid confusion, and make it easier to write portable
programs, it would be better to have distinct names for
these two distinct pairs of procedures.  Then maybe one
could be defined in terms of the other.  I don't know
if this would be possible, it would probably be slow,
but it is certainly more difficult if the two pairs of
procedures have the same names!

Since the defining characteristic of the SRFI system is that
there are no special syntax objects, just lists of
identifiers, they might be called |datum->syntax-list| and
|syntax-list->datum|, or just go back to the original
shorter names.

-- 
     -- Keith Wright

Programmer in Chief, Free Computer Shop
 ---  Food, Shelter, Source code.  ---