The power of Lists Keith Wright (15 Aug 2005 03:14 UTC)
Re: The power of Lists Jens Axel Søgaard (15 Aug 2005 20:43 UTC)
Re: The power of Lists Keith Wright (16 Aug 2005 04:16 UTC)
Re: The power of Lists Michael Sperber (16 Aug 2005 06:19 UTC)
Re: The power of Lists Andre van Tonder (19 Aug 2005 13:35 UTC)
Re: The power of Lists Michael Sperber (20 Aug 2005 07:00 UTC)
Re: The power of Lists Andre van Tonder (20 Aug 2005 15:28 UTC)
Re: The power of Lists Andre van Tonder (22 Aug 2005 14:30 UTC)

Re: The power of Lists Andre van Tonder 19 Aug 2005 13:35 UTC

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