How to use dynamic-extent declarations...
in [Lisp]
|
Prev: online shopping
Next: python admin abuse complaint
From: Frode V. Fjeld on 2 Feb 2010 10:53 Paul Khuong <pvk(a)pvk.ca> writes: > At the time the &rest list is bound, everything it contains is > "otherwise accessible". Agreed, my statement was quite mistaken. Thanks for the explanation. > [..] > (let ((x (list (cons ...) ...))) > (declare (dynamic-extent x)) > (first x)) > > [..] In the [..] example above, the first time x is bound, the cons to > which x is bound is otherwise inaccessible (trivially, every reference > to that cons must pass through that very cons), but so are the rest of > the list and the first element in the list (again, every path to these > data must go through the *cons* that is bound to x). I agree wrt. your example. However, Pascal's original example was this: (defun definer (x) (list x)) (declaim (inline caller)) (defun caller (&rest args) (declare (dynamic-extent args) (optimize (speed 3) (debug 0) (safety 0) (compilation-speed 0))) (apply #'definer args)) (defun test () (caller (list 0))) The question as I understand it is whether the last (list 0) can be stack-allocated. This form is outside the (lexical) scope of the dynamic-extent declaration. I suspect what happens is that inlining "caller" causes (list 0) to be treated as it's in that lexical scope? So if there was no inlining, there would be no error? In other words, it seems to me that the question is not one of how dynamic-extent works, but rather the interplay between inlining and dynamic-extent declarations. Shouldn't you be able to declare something inline without having to concern yourself with whether some particular (or rather every) combination of caller and callee is compatible? It seems clear to me that you want inlined forms to inherit e.g. type declarations from the surrounding lexical environment, but less clear that dynamic-extent declarations should be propagated. -- Frode V. Fjeld
From: Frode V. Fjeld on 2 Feb 2010 10:54 pjb(a)informatimago.com (Pascal J. Bourguignon) writes: > Yes, inlineness is irrelevant here. I tried your example, and (as I expected) it only crashed when the function was inlined. -- Frode V. Fjeld
From: Frode V. Fjeld on 2 Feb 2010 10:56 "Frode V. Fjeld" <frode(a)netfonds.no> writes: > pjb(a)informatimago.com (Pascal J. Bourguignon) writes: > >> Yes, inlineness is irrelevant here. > > I tried your example, and (as I expected) it only crashed when the > function was inlined. I apologize, "your" refers to the other Pascal :) -- Frode V. Fjeld
From: Pascal Costanza on 2 Feb 2010 11:24 On 02/02/2010 16:40, Tim Bradshaw wrote: > On 2010-02-02 14:00:57 +0000, Pascal Costanza said: > >> There should be a 'shallow dynamic-extent' declaration that doesn't >> reach out for objects allocated at the call site... > > Does this happen when the function is not declared inline? No, then everything is fine. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Pascal J. Bourguignon on 2 Feb 2010 11:33
Pascal Costanza <pc(a)p-cos.net> writes: > On 02/02/2010 16:40, Tim Bradshaw wrote: >> On 2010-02-02 14:00:57 +0000, Pascal Costanza said: >> >>> There should be a 'shallow dynamic-extent' declaration that doesn't >>> reach out for objects allocated at the call site... >> >> Does this happen when the function is not declared inline? > > No, then everything is fine. .... _appears_ to be fine. It's just that in that case, the compiler doesn't profit from the dynamic-extent declaration, but if it was smarter or harder-working, it could still allocate the argument specially. -- __Pascal Bourguignon__ |