Re: Proposal #13: Structure Sharing in Arguments

[shebs%utah-orion@utah-cs.arpa (Stanley Shebs)]

In article <8607232003.AA00325@tekchips.TEK> willc%tekchips.tek.csnet@CSNET-RELAY.ARPA writes:
>
>    Similarly, a function that takes a &REST argument should not
>    destructively modify it because in some implementations its top-level
>    list structure might share with a list that the user gave as the last
>    argument to APPLY.
>
>This clarification will imply that any accurate account of the semantics
>of Common Lisp must explain the procedure call mechanism in terms of
>linked lists.

This doesn't make any sense.  The clarification *simplifies* the
semantics of Common Lisp because it leaves undefined the situation
in which someone destructively modifies an &rest argument.  "Bottom"
is simpler than anything else, eh?

>  It will imply that people who care about portable code
>must make a habit of copying every &REST argument themselves, despite
>the fact that in any reasonable implementation the &REST argument will
>have been freshly consed.  It will force people who care about efficiency
>to write non-portable code.  This clarification is a very bad thing.

People who go about writing lots of destructive operations are best
off making copies of their data structures before starting to beat on them.
It's not perfect referential transparency, but it goes a long way to
getting predictable code.

"Reasonable implementation" is a pretty loaded term.  If &rest args are all
freshly consed, then it compromises efficiency *all* the time, not just
the cases where someone decides that destructive operations are the thing
to do.

>Does anyone claim that this clarification is a good thing?

I do.  (It is of course only a coincidence that PCLS *does* share arglist
pieces!)  This clarification fits well with those parts of the standard
that don't promise whether DELETE and REMOVE have distinguishable behavior,
or how many bits are in a short float, etc.

								stan