Re: the sort function in lisp (destructive)

XL> lisp that's rather bizarre. That is: its “sort” function destroys the
XL> variable of list it is sorting!!!

if you do not understand the difference between variable and data it refers
to, you probably understand nothing about Lisp.
variable is just a reference or a pointer to data.

no function in CL can affect _variable_ that is passed as parameter to the
function. but it can affect data.

XL> This actually caused me few hours to debug.

it seems you know the word "destructive", don't you?

if you use function that is documented to be destructive, but you do care
about your data, you should copy your data.
that seems to be easy and intuitive rule.

XL> Lisp's big baggage ...etc.), but what could have possibly made the
XL> design of “sort” function the way it is?

i guess it's destructive by default because often you do sort a freshly
created list, and rarely you do need both sorted and non-sorted list.
in case somebody needs it, it's fairly easy to do so calling copy-list
function or something like this.

there's no sortf macro (only macro can interact with parameters passed to
it) because it's not widely used pattern -- i think typically people just
return what sort returns.

it's fairly easy to make sortf macro yourself, something like:

(defmacro sortf (seq-place predicate) `(setf ,seq-place (sort ,seq-place
,predicate)))

and you'll have what you call "in-place sort".

i agree that it would be more newbie-friendly to have either non-destructive
sort by default or sortf,
but Common Lisp is not a newbie-oriented language, and more experienced Lisp
programmers use SORT without problems (or they can easily define function or
macro that fits them better).

if newbies will spend some hours debugging weird SORT behaviour it would be
better for them -- that way they'll understand understand faster what does
word "destructive" mean and how variables do work.


.

Relevant Pages

  • Re: Sorting by enumeration
    ... sort on the second field, ... But since Lisp only has "less than" ... to have to do some equals testing as well. ... Optimization is a good looking trap but I prefer to avoid it. ...
    (comp.lang.lisp)
  • Re: I would appreciate a code review
    ... > through Paul Graham's ANSI Common Lisp book. ... SORT is mentioned after page 56. ... Don't forget, once you have the matching alist entry, you can: ...
    (comp.lang.lisp)
  • Re: Sorting by enumeration
    ... sort on the second field, ... But since Lisp only has "less than" ... to have to do some equals testing as well. ... Optimization is a good looking trap but I prefer to avoid it. ...
    (comp.lang.lisp)
  • Re: the sort function in lisp (destructive)
    ... |> For example, to avoid having two different sort algorithms, or even ... I think there are two many `if's in reasoning about memory access ... On the random permuter, I'm really very sorry, but I have no access to ... the original lisp. ...
    (comp.lang.lisp)
  • CL subset?
    ... language in a conscious effort to create smaller distributables. ... case of COMPILE and friends, they wouldn't be giving up much at all. ... it seems the most obvious way to implement this sort of thing is to ... LISP" question. ...
    (comp.lang.lisp)