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.
On Tue, 16 Aug 2005, Michael Sperber wrote:
Andre has shown that the issue can be worked around. This has both benefits of convenience and quite substantial cost. We're having an argument over whether the cost is worth the convenience. I can see why someone would argue that the convenience is worth it. I don't agree.
I think the cost is worth it. It is a one-time burden on the implementor that gives significant (in my experience) convenience to users in perpetuity. The
cost is bounded but the savings over all user programs is potentially infinite.The cost is at worst a memory issue at expand-time for vast programs or long REPL runs, and has been argued to be solvable. The workaround shows that the efficiency of car/cdr need not be affected in the least. What is more, genericity of car/cdr has been argued to be precisely an abstraction device - not, as has been claimed, a breaking of the abstraction.
Leaving the specification as is imposes the least burden on either camp in this issue. Those who like programming with explicit type conversions can define syntax->list as the identity. Those who instead prefer to manipulate syntax as lists can do so easily.
On the other hand, making syntax opaque to list operations would impose a far larger burden on latter than the former. To me this is a point in favour of
the current specification.Tangentially, the current specification is compatible with both psyntax and MzSyntax, once syntax->list and syntax-e have been defined as the identity.
Making syntax objects opaque to list operations would break psyntax macros.The current specification supports both the defmacro and the pattern-matching paradigms equally well. Changing to list-opaque syntax objects would most decidedly favour the pattern-matching paradigm and deprecate the defmacro paradigm. I would prefer the design to be agnostic to the user's taste in paradigms.
So my vote is likely to go towards more convenience for a wider overall base of users in the long run rather than one-time implementor convenience.
Andre