Subject: [clisp-list] bug report

From: "Fuliang Weng (RTC)" <[email-masked]>
Date: Tue Sep 17 08:53:01 2002

Dear Mr. Bruno Haible and others,

I am using CLISP for some applications. I noticed that there is a 
problem with the interpretation of "quote" and "function".

Based on the definition in Steele et al 's book "Common Lisp: the 
Language" 1st and 2nd eds, when you perform:

(setq x '(a quote c))

it is normally interpreted as:

(a quote c)

However, if you try this in CLISP, you will get:

(A . 'C)

The same thing happens to "function"

when you input:

(setq x '(a function c))

You will get the following in CLISP:

(A . #'C)

intead of the normal interpretation:

(A FUNCTION C)  

I am wondering whether this is what you intended. If not, what could an 
easy fix?

Thanks.

--Fuliang

---

From: "John K. Hinsdale" <[email-masked]>
Date: Tue Sep 17 09:03:06 2002

> However, if you try this in CLISP, you will get:

I think this is just a problem with how it is displaying the list.
Internally it does look like it's being computed right.  Not that this
isn't confusing :)

E.g.:

[1]> (setq x '(a quote c))
(A . 'C)
[2]> (describe x)

(A . 'C) is a list of length 3.

[3]> (describe (car x))

A is the symbol A, lies in #<PACKAGE COMMON-LISP-USER>, is accessible in the package COMMON-LISP-USER.
....

[4]> (describe (cadr x))

QUOTE is the symbol QUOTE, lies in #<PACKAGE COMMON-LISP>, is accessible in the packages CLOS, COMMON-LISP, COMMON-LISP-USER, EXT, FFI, 
POSIX, REGEXP, SCREEN, SYSTEM, WILDCARD, names a special operator.
 
...

[5]> (describe (caddr x))

C is the symbol C, lies in #<PACKAGE COMMON-LISP-USER>, is accessible in the package COMMON-LISP-USER.
 
...

---

From: "Fuliang Weng (RTC)" <[email-masked]>
Date: Tue Sep 17 10:20:04 2002

Ok, I am more interested in getting the normal interpretation for the 
tasks I am doing.
For example, when a function reads in a sentence represented in a list 
(he said it does not function well) and then print it out, and you will 
see (he said it does not . #'well). That's not just a displaying problem;)

I would like to hear any neat and clean solutions to this (not just 
treat a sentence as a string). Thanks.

--Fuliang

---

From: Kaz Kylheku <[email-masked]>
Date: Tue Sep 17 10:57:04 2002

On Tue, 17 Sep 2002, Fuliang Weng (RTC) wrote:

> Date: Tue, 17 Sep 2002 10:13:59 -0500
> From: "Fuliang Weng (RTC)" <[email-masked]>
> To: John K. Hinsdale <[email-masked]>
> Cc: [email-masked],
>      Fuliang Weng <[email-masked]>
> Subject: Re: [clisp-list] bug report
> 

That is funny.  But it *is* just a displaying problem. The above notation
is equivalent to:

    (he said it does not . (function well))

which is equivalent to

    (he said it does not function well)

It's just confusing to a human, that is all. :)

> treat a sentence as a string). Thanks.

The neat solution is not to employ symbols from the COMMON-LISP package
for your own use.  If you are reading symbolic data from a file or user
interface, use your own package!

[14]> (defpackage :fuliang)
#<PACKAGE FULIANG>
[15]> (in-package :fuliang)
#<PACKAGE FULIANG>
FULIANG[16]> '(he said it does not function well)
(HE SAID IT DOES NOT . #'WELL)
FULIANG[17]> (shadow :function)
T
FULIANG[18]> '(he said it does not function well)
(HE SAID IT DOES NOT FUNCTION WELL)

---

From: "Fuliang Weng (RTC)" <[email-masked]>
Date: Tue Sep 17 14:46:03 2002

Kaz Kylheku wrote:

which is equivalent to

I guess that I should have used "the normal representation" instead of "the normal interpretation".
In my tasks, the representation is important. I understand that these lists are equivalent, but they are
very different for my purposes. To use an analogue, if you are given a set of axioms, it does not mean that people don't need to have all the other theorems because they are all implied. In my case, if another module uses the output with this representation, it won't understand.

It is not just reading in or outputing, they need to be processed in other functions. With the CMU CL, I don't have this problem, it returns in the way I want.

* (setq x '(he said it does not function well))
(HE SAID IT DOES NOT FUNCTION WELL)

The problem with your solution is that both "quote" and "function" can't be used as the functions in lisp, which I am hesitating to do...

Thanks for the suggestion, though.

---

From: Sam Steingold <[email-masked]>
Date: Tue Sep 17 18:52:04 2002

> * In message <[email-masked]>
> * On the subject of "[clisp-list] Re: bug report"
> * Sent on Tue, 17 Sep 2002 21:43:03 +0000
> * Honorable "Fuliang Weng (RTC)" <[email-masked]> writes:

> (HE SAID IT DOES NOT FUNCTION WELL)

the above is the correct solution.  use it.

FUNCTION and QUOTE are special operators in Common Lisp, and it is
highly unwise to use them in any way in your data (in CL, data is code)

I hope you will hit a package lock error soon - this will reinforce
this point that several people have made before me already.

> It is not just reading in or outputing, they need to be processed in other
> functions. With the CMU CL, I don't have this problem, it returns in the way I want.
> The problem with your solution is that both "quote" and "function" can't be used as the
> functions in lisp, which I am hesitating to do...

I think you are confused by the printed representation.
For some unfathomable reason you want the printed representation to
appear the way you envision.
There are many ways to achieve this, and the way you use is the wrong one.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Lisp suffers from being twenty or thirty years ahead of time.

---

From: Mario Mommer <[email-masked]>
Date: Tue Sep 17 23:50:04 2002

I checked back in the HyperSpec, and this is what I found:

http://www.lispworks.com/reference/HyperSpec/Body/s_quote.htm#quote

http://www.lispworks.com/reference/HyperSpec/Body/02_dc.htm

http://www.lispworks.com/reference/HyperSpec/Body/02_dca.htm

'<something> is a shortcut for (quote <something>) and not the other way 
arround, and thus the behavior expected by Mr. Weng is the correct one, 
at least according to the standard.

Same for function. See

http://www.lispworks.com/reference/HyperSpec/Body/02_dhb.htm

Regards,
	Mario.

---

From: Kaz Kylheku <[email-masked]>
Date: Wed Sep 18 08:23:04 2002

> at least according to the standard.

You want Lisp to recover the shorthands from the list structure also. 

When I write

    (print '(defvar *list* '(a b c)))

I want to see

    (DEFVAR *LIST* '(A B C))

not

    (DEFVAR *LIST* (QUOTE (A B C)))

---

From: "Mario S. Mommer" <[email-masked]>
Date: Wed Sep 18 09:55:06 2002

On Wed, 18 Sep 2002 08:22:44 -0700 (PDT)
>     (DEFVAR *LIST* (QUOTE (A B C)))

That is why you set *print-pretty* to t

Usually you have *print-pretty* set to nil, and if you want to print
code, you use pprint instead of print.

then

(print '(defvar *list* '(a b c)))
==> (DEFVAR *LIST* (QUOTE (A B C)))

but

(pprint '(defvar *list* '(a b c)))
==> (DEFVAR *LIST* '(A B C))

The solution to what bugged mr. Weng would normaly be to set
*print-pretty* to nil. But CLISP prettyprints everything, ignoring
*print-pretty*

Regards,
	Mario.

---

From: "Fuliang Weng (RTC)" <[email-masked]>
Date: Wed Sep 18 09:58:06 2002

I guess that I am not that comfused by the prented representation. But, I am really confused by the  behaviors of the printed representation, see the following:

[1]> (setq x '(quote a b c))
(QUOTE A B C)
[2]> (setq x '(a quote b c))
(A QUOTE B C)
[3]> (setq x '(a b quote c))
(A B . 'C)
[4]> (setq x '(a b c quote))
(A B C QUOTE)
[5]>

Don't you think something needs to be done for the consistency;)

--Fuliang

Kaz Kylheku wrote:

When I write

I want to see

(DEFVAR *LIST* '(A B C))

not

---

From: "Pierpaolo BERNARDI" <[email-masked]>
Date: Wed Sep 18 12:06:09 2002

> treat a sentence as a string). Thanks.

(setq *print-pretty* nil)

P.

---

From: "Fuliang Weng (RTC)" <[email-masked]>
Date: Wed Sep 18 12:27:17 2002

Tried, not working -- same problem.

Pierpaolo BERNARDI wrote:

P.

---

From: "Pierpaolo BERNARDI" <[email-masked]>
Date: Wed Sep 18 12:37:03 2002

From: Fuliang Weng (RTC) 

> Tried, not working -- same problem.

You are right.  Now I remember better.

It's a long standing bug. 

It's easily fixable, and I also submitted a patch years ago.
Bruno, however, prefers the current behaviour.

P.

---

From: Kaz Kylheku <[email-masked]>
Date: Wed Sep 18 13:04:02 2002

On Wed, 18 Sep 2002, Fuliang Weng (RTC) wrote:

> Date: Wed, 18 Sep 2002 12:25:27 -0700
> To: Pierpaolo BERNARDI <[email-masked]>

If you are interning new symbols at run time, for example by obtaining
sentences from a user and treating words as symbol names, you should
probably be doing that in a dedicated package. Otherwise you are
interning symbols in the COMMON-LISP-USER package. This package imports
symbols from COMMON-LISP, so whenever the reader encounters the name of
a COMMON-LISP symbol, it just returns that symbol instead of interning
a new one. So your user's sentence list then actually contains a
mixture of pointers to symbols in COMMON-LISP-USER and to symbols in
COMMON-LISP, like QUOTE and FUNCTION.

If you do this, you have no way to clean up after the user! Interned
symbols are not garbage collected, because their home packages serve
as root references; so long as a symbol is in a package, it is always
referenced. Thus by interning symbols at run time, you risk creating
permanent pollution.

If you intern symbols in your own custom package, you can use
DELETE-PACKAGE to get rid of all of them when you are done. You
probably don't want to be doing that on your COMMON-LISP-USER package!

---

From: Sam Steingold <[email-masked]>
Date: Wed Sep 18 13:52:04 2002

> * In message <[email-masked]>
> * On the subject of "Re: bug report"
> * Sent on Wed, 18 Sep 2002 08:57:16 -0700
> I guess that I am not that comfused by the prented representation. But, I am really
> confused by the  behaviors of the printed representation, see the following:

hint: special operator QUOTE takes one single argument.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
An elephant is a mouse with an operating system.

---

From: "Pierpaolo BERNARDI" <[email-masked]>
Date: Thu Sep 19 05:52:06 2002

From: "Sam Steingold" <[email-masked]>

> appear the way you envision.

I think his expectations are completely reasonable.

Check 22.1.3.5 in the Hyperspec.

P.