* Bjoern Hoefling
| Hello everybody,

hi, there,

| I have traced down a problem in a big part of code to the following
| strange behaviour of sort:

actually, the behavior of `sort' is well documented and returning values
through side effects it _not_ an established pattern in Lisp, so it's your
expectations that are strange (for Lisp, but not necessarily for another
language).

| USER(4): (setf ll (cons "b" ll))
| ("b" "a" "c" "d" "f")
| USER(5): (sort ll #'string<)
| ("a" "b" "c" "d" "f")
| USER(6): ll
| ("b" "c" "d" "f")
| 
| Certainly this might be encompassed by always doing an explicit setf
| after sorting.  But with this strange effect I would like to know whether
| the return value of sort is guaranteed to be correct.

this is indeed a strange way to think.  just because the side effect is
different from your expectations, doesn't mean you can doubt the return
value.  Lisp functions are usually defined in terms of their return values,
and not in terms of their side effects.  (other languages have other ways.)

note that `sort' is unable to know where to store the return value, and
that if `sort' is called on a list, there is no way to store a pointer to
the first element.  if `sort' is called on a vector, it will obviously be
able to return its value by side effect to the vector, but that is an
accident.

the morale of this story is that you should always store the return value
of a function if you need the return value.

#\Erik