Path: utzoo!attcan!uunet!husc6!purdue!tlh
From: tlh@cs.purdue.EDU (Tom "Hey Man" Hausmann)
Newsgroups: comp.lang.lisp
Subject: Re: Kyoto Common LISP bug (SORT function)
Summary: It's documented.
Keywords: bugs, bugs, bugs
Message-ID: <4322@medusa.cs.purdue.edu>
Date: 10 Jun 88 20:22:22 GMT
References: <10988@cgl.ucsf.EDU>
Organization: Computing About Physical Objects Project
Lines: 33

In article <10988@cgl.ucsf.EDU>, yee@cgl.ucsf.edu (dave yee) writes:
> I think i've found a bug in KCL (Kyoto Common LISP).  I'd like to know if
> (1) anyone has also seen/experienced this bug and
> (2) if there is a fix.  Should a fix exist, could you direct me to it?
> We are running KCL on a SUN 3/280
> The problem is with sort and stable-sort.  Suppose
> i have a structure of the following form:
>      (defstruct box
> 	(item-code nil))
> now, given a list of boxes, i would like to sort them by item-code number.
> for example,
>      (setq sorted-boxes (sort unsorted-boxes #'< :key'box-item-code))
> well, the function returns the correct value, BUT the original
> list is not sorted, furthermore *elements of the list are missing*!!!
> Now, i'm still a beginner, but if this is a feature of KCL i would
> appreciate an explanation as to why.  Oh, and i should add that i've
> tested this using SUN Common LISP and the problem does *not* exist.
> Any suggestions?
> -dave: 

   In CLtL sort is *destructively* sorts a lists and retruns the sorted
   list.  Thus your problem is not a bug in KCL.

   I have also experienced this when I ported someone else's code from
   the Symbolics to KCL environment.  The person assumed sort on the
   Lispm would not destroy the list.

   -Tom
-------------------------------------------------------------------------------

Tom Hausmann       Dept. of Computer Sciences     Purdue University
tlh@medusa.cs.purdue.edu     | My ideas?  There has never been an original
...!purdue!tlh               | thought since Plato.