Is this a bug in LispWorks?

Discussion of Common Lisp
Post Reply
lispamour
Posts: 18
Joined: Wed Jun 02, 2010 12:29 am

Is this a bug in LispWorks?

Post by lispamour » Thu Jun 10, 2010 2:01 am

I'm getting started in Lisp, and working through the problems in Lisp: Gentle Introduction to Symbolic Computation. In Chapter 8 p. 217 is the following Exercise 4:

Write MAPUNION, an applicative operator that takes a function and a list as input, applies the function to every element of the list, and computes the union of all the results. Example:

Code: Select all

 (MAPUNION #'CDR '((1 a b c) (2 e c j) (3 f a b c d)))
should return the set
(a b c e j f d).
Here is my solution:

Code: Select all

       (defun mapunion (f l)
               (cond ((null l)                     nil)
                        ((null (mapcar f l)     nil)
                        (t                             (reduce #'union (mapcar f l)))))
Simple right? Well it crashes under Lispworks (Personal Edition 5.1.1 PowerPC) But works fine under Clozure CL64 (Version 1.4-dev (13119 (PPC64)).

The error message I get back from Lispworks is:

Code: Select all

CL-USER 3 > (mapunion #'cdr '((1 a b c) (2 e c j)))

Error: Illegal instruction(4) [code 20EFE1A0] at 20EFEB78
  1 (abort) Return to level 0.
  2 Return to top loop level 0.

Type :b for backtrace, :c <option number> to proceed,  or :? for other options

CL-USER 4 : 1 > :b
Call to ERROR
Is there something wrong with my code that would cause it to crash under Lispworks but not Clozure?

ramarren
Posts: 613
Joined: Sun Jun 29, 2008 4:02 am
Location: Warsaw, Poland
Contact:

Re: Is this a bug in LispWorks?

Post by ramarren » Thu Jun 10, 2010 5:43 am

Your code as posted has unbalanced parentheses, so it is hard to tell. Also, the second branch is redundant with the first.

gugamilare
Posts: 406
Joined: Sat Mar 07, 2009 6:17 pm
Location: Brazil
Contact:

Re: Is this a bug in LispWorks?

Post by gugamilare » Thu Jun 10, 2010 7:54 am

It might be a bug in Lispworks. Do you have downloaded their latest version? Also, did you check the parenthesis, didn't you make some mistake while copy-and-pasting the code?

lispamour
Posts: 18
Joined: Wed Jun 02, 2010 12:29 am

Re: Is this a bug in LispWorks?

Post by lispamour » Thu Jun 10, 2010 12:05 pm

Ramarren wrote:Your code as posted has unbalanced parentheses, so it is hard to tell.
I'll try again below:

Code: Select all

(defun mapunion (f l)
  (cond ((null l)              nil)
        ((null (mapcar f l))   nil)
        (t                     (reduce #'union (mapcar f l)))))
Also, the second branch is redundant with the first.
How would you re-write it?

lispamour
Posts: 18
Joined: Wed Jun 02, 2010 12:29 am

Re: Is this a bug in LispWorks?

Post by lispamour » Thu Jun 10, 2010 12:10 pm

gugamilare wrote:It might be a bug in Lispworks. Do you have downloaded their latest version? Also, did you check the parenthesis, didn't you make some mistake while copy-and-pasting the code?
This is their latest version.

Code: Select all

LispWorks Personal Edition

Current Version

The current version is LispWorks 5.1.1 Personal Edition. It includes the new features announced here.

Next Version

LispWorks 6.0 Personal Edition will be released during 2010. Check our user group for announcements.
You're right. I left off a parenthesis while copying and pasting. I've corrected it in the previous post.

ramarren
Posts: 613
Joined: Sun Jun 29, 2008 4:02 am
Location: Warsaw, Poland
Contact:

Re: Is this a bug in LispWorks?

Post by ramarren » Thu Jun 10, 2010 12:29 pm

lispamour wrote:How would you re-write it?
MAPCAR will return NIL only if the list is empty, which is already checked by the first branch. Therefore the second branch will never be true, and hence is pointless. In fact unless I'm missing something the entire function could be reduced to just:

Code: Select all

(defun mapunion (f l)
  (reduce #'union (mapcar f l) :initial-value nil))
But there doesn't seem to be anything wrong as such with the code. I have no idea why it would error out on LispWorks. You should look for minimal subcomponent which fails. It is somewhat unlikely there is a bug in such fundamental constructs.

lispamour
Posts: 18
Joined: Wed Jun 02, 2010 12:29 am

Re: Is this a bug in LispWorks?

Post by lispamour » Sun Jun 13, 2010 10:26 pm

Ramarren wrote:
lispamour wrote:How would you re-write it?
MAPCAR will return NIL only if the list is empty, which is already checked by the first branch. Therefore the second branch will never be true, and hence is pointless. In fact unless I'm missing something the entire function could be reduced to just:

Code: Select all

(defun mapunion (f l)
  (reduce #'union (mapcar f l) :initial-value nil))
But there doesn't seem to be anything wrong as such with the code. I have no idea why it would error out on LispWorks. You should look for minimal subcomponent which fails. It is somewhat unlikely there is a bug in such fundamental constructs.
You're quite right about how the extraneous lines in the cond expression are superfluous. To add to the mystery, I noticed that If I were to type my earlier code directly into the LispWorks Listener, and execute the resulting function

Code: Select all

    (MAPUNION #'CDR '((1 a b c) (2 e c j) (3 f a b c d)))
then the evaluation works fine. It is only when I type the (defun MAPUNION ...) definition into an external file, then compile and load the result into LispWorks that I get the above error.

Is it possible that LispWorks is performing some sort of optimization that generates faulty code after compilation and loading, which does not occur if function were defined in the Listener's interpretive environment?

ramarren
Posts: 613
Joined: Sun Jun 29, 2008 4:02 am
Location: Warsaw, Poland
Contact:

Re: Is this a bug in LispWorks?

Post by ramarren » Sun Jun 13, 2010 11:08 pm

lispamour wrote:Is it possible that LispWorks is performing some sort of optimization that generates faulty code after compilation and loading, which does not occur if function were defined in the Listener's interpretive environment?
It seems so. You could try asking on some LispWorks specific mailing list. I guess PPC64 is not a very well supported architecture. Or maybe there is some sort of environment mismatch?

death
Posts: 17
Joined: Sat Jun 28, 2008 1:44 am

Re: Is this a bug in LispWorks?

Post by death » Tue Jun 15, 2010 5:12 pm

Tip: whenever you have (reduce <function1> (mapcar <function2> <list>) ...) you can replace it with (reduce <function1> <list> :key <function2> ...), avoiding intermediate garbage.

Post Reply