Prev: questions about packages
Next: Comprehending error messages
From: Ariel Badichi on 25 Apr 2010 16:03
RG <rNOSPAMon(a)flownet.com> writes:

>
> Even better:
>
> (defmacro sortf (place pred &rest args)
> `(setf ,place (sort ,place ,pred ,@args)))
>

This macro has the problem of multiple evaluation. Try this:

(define-modify-macro sortf (predicate &rest arguments))

Ariel
From: RG on 25 Apr 2010 18:18
In article <87d3xnfger.fsf(a)sneeze.site>,
Ariel Badichi <vermilionrush(a)gmail.com> wrote:

> RG <rNOSPAMon(a)flownet.com> writes:
>
> >
> > Even better:
> >
> > (defmacro sortf (place pred &rest args)
> > `(setf ,place (sort ,place ,pred ,@args)))
> >
>
> This macro has the problem of multiple evaluation. Try this:
>
> (define-modify-macro sortf (predicate &rest arguments))
>
> Ariel

Good point.

rg
From: Scott L. Burson on 25 Apr 2010 18:37
On Apr 25, 11:31 am, Pascal Costanza <p...(a)p-cos.net> wrote:
> On 25/04/2010 19:34, Peter Keller wrote:
> >  From "Successful Lisp" by Lamkins:
>
> > -----------------------
> > Places vs. values: destructive functions don't always have the desired
> > side-effect
>
> > A nondestructive function such as REVERSE always returns a freshly
> > constructed result, so there's never any question but that you need to
> > pay attention to the result. But a destructive function such as NREVERSE
> > sometimes modifies its argument in such a way that the changed argument
> > is identical to the function result. This leads some programmers to
> > assume that destructive functions always modify the argument to match the
> > result. Unfortunately, this is not true; leading to the second important
> > point about the use of destructive functions: you should use the result
> > of a destructive function the same way that you would use the result of
> > its nondestructive counterpart.
>
> >      This also applies to SORT and STABLE-SORT, which are destructive
> >      and do not have a nondestructive counterpart.
> > -----------------------
>
> > Since sort doesn't take a<place>  like push or remf, you can't depend the
> > side effect as having been correct.
>
> > I'd say use
>
> > (setf v (sort v predicate))
>
> > instead.
>
> Bleh, you're right... ;)

Wellll, I suppose throwing in the SETF is not a bad habit to be in,
but if you understand why it's needed for SORT of a list, and you know
that you really are sorting a vector, I don't see that it's so
terrible to leave out the SETF.

I suppose there is some chance that a less experienced Lisper, reading
your code, might get the wrong impression.

-- Scott
From: Tamas K Papp on 25 Apr 2010 18:48
On Sun, 25 Apr 2010 15:37:26 -0700, Scott L. Burson wrote:

> On Apr 25, 11:31 am, Pascal Costanza <p...(a)p-cos.net> wrote:
>> On 25/04/2010 19:34, Peter Keller wrote:
>> >  From "Successful Lisp" by Lamkins:
>>
>> > -----------------------
>> > Places vs. values: destructive functions don't always have the
>> > desired side-effect
>>
>> > A nondestructive function such as REVERSE always returns a freshly
>> > constructed result, so there's never any question but that you need
>> > to pay attention to the result. But a destructive function such as
>> > NREVERSE sometimes modifies its argument in such a way that the
>> > changed argument is identical to the function result. This leads some
>> > programmers to assume that destructive functions always modify the
>> > argument to match the result. Unfortunately, this is not true;
>> > leading to the second important point about the use of destructive
>> > functions: you should use the result of a destructive function the
>> > same way that you would use the result of its nondestructive
>> > counterpart.
>>
>> >      This also applies to SORT and STABLE-SORT, which are
>> >      destructive and do not have a nondestructive counterpart.
>> > -----------------------
>>
>> > Since sort doesn't take a<place>  like push or remf, you can't depend
>> > the side effect as having been correct.
>>
>> > I'd say use
>>
>> > (setf v (sort v predicate))
>>
>> > instead.
>>
>> Bleh, you're right... ;)
>
> Wellll, I suppose throwing in the SETF is not a bad habit to be in, but
> if you understand why it's needed for SORT of a list, and you know that
> you really are sorting a vector, I don't see that it's so terrible to
> leave out the SETF.
>
> I suppose there is some chance that a less experienced Lisper, reading
> your code, might get the wrong impression.

I am not really concerned about that. I am worried about the
possibility of not _having to_ sort a vector in place, so that an
implementation could sort a vector by making a copy. AFAIK none of
them does that, but whether that is allowed is another question.

I am not convinced by the quote from Successful Lisp: that clearly
applies to lists. The question is: could an implementation implement
sort for vectors as

(sort (copy-seq sequence) predicate)

? I will probably use the setf idiom (or the macro above) for now,
but it would be nice to know the definitive answer (based on the HS).

Tamas
From: Peter Keller on 25 Apr 2010 19:44
Tamas K Papp <tkpapp(a)gmail.com> wrote:
> I am not really concerned about that. I am worried about the
> possibility of not _having to_ sort a vector in place, so that an
> implementation could sort a vector by making a copy. AFAIK none of
> them does that, but whether that is allowed is another question.
>
> I am not convinced by the quote from Successful Lisp: that clearly
> applies to lists. The question is: could an implementation implement
> sort for vectors as
>
> (sort (copy-seq sequence) predicate)
>
> ? I will probably use the setf idiom (or the macro above) for now,
> but it would be nice to know the definitive answer (based on the HS).

In reading the HS more carefully, it would appear to provide an answer which
states that you can use the sort in the manner you initially intended
without having to perform the setf:

"The sorting operation can be destructive in all cases. In the case of
a vector argument, this is accomplished by permuting the elements in
place. In the case of a list, the list is destructively reordered in
the same manner as for nreverse."

However, the HS leaves room for ambiguity by also making this statement:

"If sequence is a vector, the result might or might not be simple,
and might or might not be identical to sequence."

It is that "might or not not be identical" which makes me want to use the setf.
Identical in this case means via eq as in the exact same object in memory.

I can see a potenital issue if you have a smaller displaced array in the
middle of a larger array and you sort the displaced array. Unless you setf
the result of the sort back into the smaller arrays' original generalized
reference into the larger array, you could get something you don't expect.

Later,
-pete
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: questions about packages
Next: Comprehending error messages