[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The power of Lists
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
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
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.