This page is part of the web mail archives of SRFI 72 from before July 7th, 2015. The new archives for SRFI 72 contain all messages, not just those from before July 7th, 2015.
> 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. ---