Prev: online shopping
Next: python admin abuse complaint
From: Duane Rettig on 4 Feb 2010 15:46
On Feb 4, 4:14 am, Pascal Costanza <p...(a)p-cos.net> wrote:
> On 03/02/2010 19:15, Duane Rettig wrote:
>
> > I've been following this conversation with interest, because it is a
> > perplexing issue.  The intention of dynamic-extent is understandable,
> > and it is clear that the "otherwise inaccessible part" doctrine should
> > apply to all parts of an object, which means it applies to trees as
> > well as lists.  What is not clear to me is whether in a philosophical
> > sense a&rest argument is a single object or a list of objects.
> > Obviously, to a function f with&rest x, x is a single object,  but to
> > a function g which calls f with arguments a, foo, and framis, all
> > three of these arguments are unrelated and should not, in my opinion,
> > be conflated as one object.
>
> > I believe that the spec does support this philosophical view.  Since
> > it is the examples section that is under scrutiny, and provides the
> > ambiguity, we should examine the text of the&rest example:
>
> The spec may or may not support this philosophical view. However, what
> is important when writing portable code is that you have to expect that
> some implementations _may_ take the more 'aggressive' (for lack of a
> better term) interpretation. Since the spec is at least ambiguous in
> this regard, you cannot blame them, so you have to account for that fact.

Yes, of course. What bothers me about this whole issue is that when
you wondered if you could ever get any real use from a dynamic-extent
declaration portably at all, it might not have been far from the
truth. The description of otherwise-inaccessible-parts seems to take
on a narrow view, and if taken fully at face value might even preclude
uses of dynamic-extent that I had otherwise thought to be obviously
correct. I have not yet responded to Paul, and I have not yet worked
through it all, but even his workaround example may not disambiguate
the otherwise-inaccessible-parts description sufficiently for any
implementation to hug all of the corner cases tightly (i.e. I
tentatively assert that if any implementation actually did all that it
could do to stack-allocate truly dynamic-extent objects, then Paul's
workaround might not be sufficient to guarantee heap allocation within
the substructure of the list). If that is indeed the case, then the
user is at the mercy of his implementation, and can't rely on the spec
wrt the dynamic-extent declaration, except for the admonition not to
use it. And that, in my opinion, would be a sad waste.

> As long as you write code for one particular implementation, you can of
> course check that implementation's documentation and then base your
> decisions on what it does and does not promise to do for dynamic-extent
> declarations.

Of course.

> What can always be enlightening in such discussions is to read what
> CLtL2 has to say about such issues - more often than not, there is more
> text, or different wordings, that reveal something about the original
> intentions of a construct that got added to Common Lisp. With regard to
> dynamic-extent, it has the following to say: "The dynamic-extent
> declaration should be used with great care. It makes possible great
> performance improvements in some situations, but if the user misdeclares
> something and consequently the implementation returns a pointer into the
> stack (or stores it in the heap), an undefined situation may result and
> the integrity of the Lisp storage mechanism may be compromised.
> Debugging these situations may be tricky. Users who have asked for this
> feature have indicated a willingness to deal with such problems;
> nevertheless, I do not encourage casual users to use this declaration."
> (cf. Section 9.2)

Not only is looking at CLtL2 useful, but it is possible to trace the
roots of CLtL2 itself, parts of which are the X3J13 issues.
Interesting stuff here: http://www.lispworks.com/documentation/HyperSpec/Issues/iss142_w.htm,
not only for the fact that so much of it made it into the spec
essentially unchanged, but also for the extra discussions as well,
especially about the integer 3 being an otherwise-inaccessible-part.

> That was exactly the mistake I made in my code: I used dynamic-extent
> declarations too casually and too liberally, when their intention was
> clearly to be used for fine-tuning performance when something has been
> identified as a bottleneck. If a dynamic-extent declaration on a &rest
> argument list turns out to be a win in a particular situation, it's
> probably also possible to rearrange the code in such a way that the
> problem I sketched in my OP doesn't show up. I understand Paul's
> comments as suggesting one possible such way, not as a replacement for
> dynamic-extent for casual use.

Well, it would be interesting to find out what the sbcl developers say
about applying the d-e declaration to the deeper parts of the &rest
argument than its top-level list; who knows, perhaps it was not
intended, in which case this conversation would be moot, since all of
the other observed behaviors seem to me to be intuitive.

Duane
First  |  Prev  | 
Pages: 1 2 3 4 5 6 7 8 9 10
Prev: online shopping
Next: python admin abuse complaint