From: Frode Vatvedt Fjeld
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <2hhf19piue.fsf@dslab7.cs.uit.no>
Kent M Pitman <······@world.std.com> writes:
> Frode Vatvedt Fjeld <······@acm.org> writes:
>
> > I think &rest parameters should have been accessed by some
> > multiple-value mechanism, not an implicitly consed list.
>
> This is an interesting choice of response. I don't really find CL
> broken in the sense that it's designed as an "industrial strength"
> language and it serves well for that purpose. But there are
> certainly some details of &rest lists that could be designed better
> in other ways if it were done again.
I certainly agree with you that the &rest issue doesn't ruin CL's
status as an industrial strength language. But the current &rest
design is broken in that--as I'm writing a compiler based on CL syntax
and semantics--it's the first (possibly only) part where I'm presented
with a choice: Be compatible with CL, _or_ implement it well. Before
approaching &rest, I never felt constrained by staying compatible with
CL.
My proposal for a better &rest would be that &rest named a local
function or macro of zero arguments that returns each of the
rest-arguments as multiple values. Then the old semantics is just an
m-v-list away, only now the consing would be explicit.
You'd also need a control structure that lets you iterate over
multiple-values. (Is there such a thing in CL currently?)
The whole point of having multiple values after all is the fact that
the slots used to pass values into and out of functions have a very
clearly defined, limited extent, and so it is just stupid to cons them
on the heap. Meaning, of course you _can_ cons them on the heap if
that is for some reason useful, but the current &rest design
_requires_ you to heap-cons, for no good reason.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld wrote:
> Meaning, of course you _can_ cons them on the heap if
> that is for some reason useful, but the current &rest design
> _requires_ you to heap-cons, for no good reason.
Unless the &rest parameter is defined DYNAMIC-EXTENT.
If performance is a problem at some particular call
then add the declaration. This seems perfectly consistent
with CL philosophy.
Paul
From: Kent M Pitman
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <sfwofvgqdyy.fsf@world.std.com>
Paul Dietz <·····@stc.comm.mot.com> writes:
> Frode Vatvedt Fjeld wrote:
>
> > Meaning, of course you _can_ cons them on the heap if
> > that is for some reason useful, but the current &rest design
> > _requires_ you to heap-cons, for no good reason.
>
> Unless the &rest parameter is defined DYNAMIC-EXTENT.
>
> If performance is a problem at some particular call
> then add the declaration. This seems perfectly consistent
> with CL philosophy.
Well, there are still some small glitches in the design.
The user can't rely on them being dynamic-extent in practice. That's
left to implementations, and perhaps rightly so.
But the'res a small semantic issue to do with the implementation
also having the right to share structure with the given list when
you do
(apply #'foo x)
The function FOO might get the actual list X (sharing structure)
or might not. This has some weird consequencies that I think I would
nail down better if I were doing a redesign, but that in practice you
can just kind of tiptoe around when you first get bitten by the
implications... or even beforehand if you think about it in time and
program defensively.