From: Kenneth Tilton on
Mirko wrote:
> I had no idea nreverse could reach this deep (amounting to shallow
> understanding/thinking?).
>
> This is the code snippet:
>
> (let ((data (tecplot-data data-pod var :type :boundary :avg avg)))
> (coerce (reverse data) 'vector)))
>
> Now (tecplot-data ... ) amounts to
>
> (aref (data object) 6)
>
> where (data object) returns a vector of 9 lists.
>
> `data' never existed in the let construct, and the direct reference to
> the original list was maintained across two function calls. Makes
> perfect sense in retrospect, but for a while I thought I was seeing
> gremlins.

Nah, just object identity. That would get maintained over even /three/
function calls. :)

kt
From: Pascal Costanza on
Bj�rn Lindberg wrote:
> Mirko <mirko.vukovic(a)gmail.com> writes:
>
>> I had no idea nreverse could reach this deep (amounting to shallow
>> understanding/thinking?).
>>
>> This is the code snippet:
>>
>> (let ((data (tecplot-data data-pod var :type :boundary :avg avg)))
>> (coerce (reverse data) 'vector)))
>
> In this particular case, the perhaps obvious solution is to reverse
> (heh) the order of the reversal and the coercion:
>
> (nreverse (coerce data 'vector))

Also dangerous, in case data is already a vector (and you don't know
whether it is one or not because you may change the other parts of your
program later).

The general rule applies: Only use optimizations if you know they
actually buy you something. A slight variant of this rule is: Only use
destructive operations on conses when they have been created in the same
function, or the other function that returns them gives strong
guarantees about their 'freshness'. When in doubt, opt for
non-destructive operations.


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/