Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: changing a symbol name

126 views
Skip to first unread message

Pascal Bourguignon

unread,
Oct 14, 2004, 1:39:44 PM10/14/04
to
"Christophe Turle" <ctu...@nospam.com> writes:
> > You're calling for deep trouble. (Hint: Symols are part of a program
> > source code.)
>
> Symbols are but why their name are ? symbol & name should be distinct.

(defparameter a :a)
(defparameter b :b)
(setf (symbol-name 'a) "B")
(print b)
==> ?

The essence of a symbol is in its name, symbols must be distinct from
other symbols. Symbol is one to its name.

> > What is it that you actually want to do?
>
> I want to rename all lisp symbols to their downcase counter part. I found
> this way to correct the bad reader uppercase convention : we write symbols
> in lower-case but as mentionned here a few days ago, we still use upper-case
> conversion for backward compatibility :(

Check readtable-case
http://www.lispworks.com/reference/HyperSpec/Body/f_rdtabl.htm

> The trouble arises when you need to mingle your code with preserve case code
> (like java). You have to use ugly '|' syntax to make all work together. And
> all that overhead because of old choices.
>
>
> Note that this is also useful when you change your mind about the name of a
> function, macro, variable or better : something you don't know all sub
> layers ...

1- use an EDITOR!!!

2- see SUBST, for example:

(subst 'good-name 'bad-name '(defun fun (bad-name other-name)
(+ bad-name other-name)))

==> (DEFUN FUN (GOOD-NAME OTHER-NAME) (+ GOOD-NAME OTHER-NAME))

3- but what implementation are you using that keep the source of the
program in core? Even clisp, mangle the source a lot:

CL-USER> (fdefinition 'fun)
#<CLOSURE FUN (BAD-NAME OTHER-NAME) (DECLARE (SYSTEM::IN-DEFUN FUN))
(BLOCK FUN (+ BAD-NAME OTHER-NAME))>
CL-USER> (function-lambda-expression 'fun)
(LAMBDA (BAD-NAME OTHER-NAME) (DECLARE (SYSTEM::IN-DEFUN FUN))
(BLOCK FUN (+ BAD-NAME OTHER-NAME)))
#(NIL NIL NIL NIL ((DECLARATION VALUES OPTIMIZE DECLARATION)))
FUN

What guarantee do you have that if you substitute in the
function-lambda-expression, the change will be applied to the function
closure?

4- Don't be silly, use an EDITOR.

--
__Pascal Bourguignon__ http://www.informatimago.com/

Voting Democrat or Republican is like choosing a cabin in the Titanic.

Thomas F. Burdick

unread,
Oct 14, 2004, 7:10:54 PM10/14/04
to
"Christophe Turle" <ctu...@nospam.com> writes:

> The trouble arises when you need to mingle your code with preserve case code
> (like java). You have to use ugly '|' syntax to make all work together. And
> all that overhead because of old choices.

This exactly what :invert readtable-case is for.

Gareth McCaughan

unread,
Oct 14, 2004, 7:32:53 PM10/14/04
to
Christophe Turle wrote:

[Pascal Bourguignon:]


> > The essence of a symbol is in its name
> >, symbols must be distinct from
> > other symbols. Symbol is one to its name.

[Christophe:]
> For you perhaps, but this is not the case of people like me who see symbols
> as concepts. Do you know about "le triangle sémiotique : référent, signifié,
> signifiant".
...
> - Concepts and names are not the same. One concept may even have different
> names. Else we were all speaking the same language (human ones).
>
> - The name is just a "pointer" to the symbol. A way to reference it.

Indeed, concepts and names are not the same. But concepts and
symbols are not the same either. Why do you expect symbols to
behave more like concepts than like names?

> - you can change a name by an other and your program will still behave the
> same way. If you change a concept from an other, it won't work the same way.

This is not a helpful test for the purpose of deciding
whether symbols are like names or like concepts, because
(as you have discovered) you can't make the sort of change
to symbols that you want to make :-).

>>> I want to rename all lisp symbols to their downcase counter
>>> part. I found this way to correct the bad reader uppercase
>>> convention : we write symbols in lower-case but as mentionned
>>> here a few days ago, we still use upper-case conversion for
>>> backward compatibility :(

Well, you want something that Lisp offers no way to do.
You'd have the same problem if you were writing in C++
and wanted a way to make it treat identifiers case-insensitively,
or if you were writing in Fortran and wanted a way to make it
dynamically typed. Actually, a better analogy: it's as if
you were writing in just about any language and wanted to
replace all its keywords with Japanese translations -- and
weren't prepared to accept solutions involving macro
preprocessors, new namespaces, etc.

I happen to think that this restriction imposed by Lisp
is a reasonable one, and that what you want to do is a
silly thing to want to do. Presumably you think it's a
silly restriction, and that what you want to do is reasonable.
Be all that as it may, you can't do it. Not only because you
can't change the name of a symbol, but also because you can't
change the attributes[1] of symbols in the COMMON-LISP package.

[1] I'd say "properties", but that has a more specific
meaning.

>> Check readtable-case
>> http://www.lispworks.com/reference/HyperSpec/Body/f_rdtabl.htm
>
> It's not sufficient. See example below.
...
> (gen-java-code ()
> (let ((modifiers '(public)))
> `(class ,@modifiers Toto) ))

So. You want symbols to be read case-preservingly because
that fits whatever Java thing you're doing, but you want
to be able to use the ordinary symbols of CL in lowercase
because uppercase is so awful. Bad news: the language
doesn't permit that. You can complain about the language,
or you can find another mechanism for your Java names.
How about strings? Or you can use the perfectly adequate
mechanism Lisp already has for getting arbitrary characters
into symbol names: |Toto|.

You don't like uppercase letters and you don't like vertical
bars? Then you can't have what you want. Too bad. You also
can't make Java case-fold its input and have all its keywords
changed to upper-case. :-)

*

I've been a bit harsh here. Maybe you have a really good
reason for wanting to do what you say you want to do. But
you haven't given one yet; you've just said "I want this"
and "I want that". Tell us *why* vertical bars, or using
strings instead of symbols, or putting the reader in case-invert
mode and hacking your Lisp-to-Java interface code to invert
the case of symbols, isn't good enough.

--
Gareth McCaughan
.sig under construc

Christophe Turle

unread,
Oct 14, 2004, 4:01:53 PM10/14/04
to
"Jon Boone" <ipmo...@delamancha.org> a écrit dans le message de
news:m3k6tt5...@spiritus.delamancha.org...
> "Christophe Turle" <ctu...@nospam.com> writes:
>
> > Yes, i'm currently trying to wrap all exported symbols from CL in their
> > downcase counterpart.
>
> Just use the following settings for readtable-case and *print-case*:

not sufficient.

> readtable-case :PRESERVE

When you can do that it's already too late for cl symbols. They are already
in uppercase. So you will have to write them in uppercase and it's what i
want to avoid.

> *print-case* :DOWNCASE
>
> You get this input/output:
>
> ZEBRA ZEBRA
> Zebra Zebra
> zebra zebra
>
> --jon


--

___________________________________________________________
Christophe Turle.
(format nil "~S@~S.~S" 'c.turle 'wanadoo 'fr)

sava preview : http://perso.wanadoo.fr/turle/lisp/sava.html


Jon Boone

unread,
Oct 14, 2004, 4:37:47 PM10/14/04
to
"Christophe Turle" <ctu...@nospam.com> writes:

> When you can do that it's already too late for cl symbols. They are already
> in uppercase. So you will have to write them in uppercase and it's what i
> want to avoid.

Ah, then you want the allegro "modern" environment.

--jon

Christophe Turle

unread,
Oct 14, 2004, 5:23:09 PM10/14/04
to
"Jon Boone" <ipmo...@delamancha.org> a écrit dans le message de
news:m3fz4h5...@spiritus.delamancha.org...

It seems.

Barry Margolin

unread,
Oct 14, 2004, 7:44:31 PM10/14/04
to
In article <416eb92f$0$547$626a...@news.free.fr>,
"Christophe Turle" <ctu...@nospam.com> wrote:

> "Peter Seibel" <pe...@javamonkey.com> a écrit dans le message de
> news:m3hdoxj...@javamonkey.com...
> > "Christophe Turle" <ctu...@nospam.com> writes:
> >
> > > "Frode Vatvedt Fjeld" <fro...@cs.uit.no> a écrit dans le message de
> > > news:2hfz4h5...@vserver.cs.uit.no...
> > >> "Christophe Turle" <ctu...@nospam.com> writes:
> > >>
> > >> > I want to change a symbol name. But it is an error to do that, why ?
> > >>
> > >> If the symbol is interned, or probably even member of any other
> > >> kind of hash-table, changing its name will lead to massive
> > >> confusion.
> > >
> > > And why ? I think the contrary. If internally all, has it should be,
> > > reference are made to the symbol, there's no problem, all is still
> > > ok.
> >
> > But you need to also be able to find the same symbol later, i.e. from
> > READ.
>
> No. As soon as you have change the name of the symbol, this name is no more
> bound. So a read call with old-name will intern a new symbol. But a read
> with a new name will catch the wanted symbol.

No it won't, because the symbol will still be in the hash bucket
associated with the old name.

To fix this, symbols would have to keep track of all the packages that
they're interned in, so that they can all be rehashed after you change
the symbol name. This is not traditionally how packages worked, so it
was not included in the Common Lisp specification.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Frode Vatvedt Fjeld

unread,
Oct 14, 2004, 2:14:40 PM10/14/04
to
"Frode Vatvedt Fjeld" <fro...@cs.uit.no> a écrit dans le message de

>> If the symbol is interned, or probably even member of any other


>> kind of hash-table, changing its name will lead to massive
>> confusion.

"Christophe Turle" <ctu...@nospam.com> writes:

> And why?

Because the intern function must be able to map a string and a package
to the exact same symbol. In practice, the package is (the equivalent
of) a hash-table where the key is the symbol-names and the values the
symbol objects.

> How many times did you redefine a function or variable just to
> change its name ? a setf/symbol-name should have been more coherent,
> no?

Most certainly not. To the extent functions have names (strictly
speaking, it's only the other way around: names have functions), these
names are _symbols_, not strings. If you want to change the name of a
function, you change to a new symbol, not a new symbol-name.

For example:

(setf (symbol-function 'new-name) (symbol-function 'old-name))

is one way to "rename" a function named old-name to new-name.

> If someone has put the symbol name in a hashtable, it is bad
> design. The key should have been the symbol not its representation.

Many implementation will

> I think the contrary. If internally all, has it should be, reference
> are made to the symbol, there's no problem, all is still ok.

Trust me, massive confusion awaits anyone taking this path.

--
Frode Vatvedt Fjeld

Christophe Turle

unread,
Oct 14, 2004, 3:35:14 PM10/14/04
to
"Peter Seibel" <pe...@javamonkey.com> a écrit dans le message de
news:m3d5zlj...@javamonkey.com...

> "Christophe Turle" <ctu...@nospam.com> writes:
>
> > "Peter Seibel" <pe...@javamonkey.com> a écrit dans le message de
> > news:m3hdoxj...@javamonkey.com...
> >> "Christophe Turle" <ctu...@nospam.com> writes:
> >>
> >> > "Frode Vatvedt Fjeld" <fro...@cs.uit.no> a écrit dans le message de
> >> > news:2hfz4h5...@vserver.cs.uit.no...
> >> >> "Christophe Turle" <ctu...@nospam.com> writes:
> >> >>
> >> >> > I want to change a symbol name. But it is an error to do that, why
?
> >> >>
> >> >> If the symbol is interned, or probably even member of any other
> >> >> kind of hash-table, changing its name will lead to massive
> >> >> confusion.
> >> >
> >> > And why ? I think the contrary. If internally all, has it should be,

> >> > reference are made to the symbol, there's no problem, all is still
> >> > ok.
> >>
> >> But you need to also be able to find the same symbol later, i.e. from
> >> READ.
> >
> > No. As soon as you have change the name of the symbol, this name is
> > no more bound. So a read call with old-name will intern a new
> > symbol. But a read with a new name will catch the wanted symbol.
>
> Hmmmm. You should probably meditate on how Lisp is going to load a
> FASL file that contains code that refer to symbols using their old
> names.

Perhaps FASL should refer to symbols by other means.

> Or in other words, what representation of symbols do you
> propose Lisp should store in a FASL file that will allow the loader to
> locate the right symbol in the current image when you load the FASL?

Good question but an implementation one (not my cup of tea).

In your image and fasl you may have a map between names and concepts.
Substitute symbols from FASL (whatever internal object it is) by symbols
having the same name in image.

ex: image (name1->symb1 ...)
fasl (name1->symb2 ...)

replace symb2 by symb1 in code from FASL when loading the file.

I don't say it is efficient. Surely all cases are not covered. But i think
it's possible and others may provide better implementations and ideas.

> > Yes, i'm currently trying to wrap all exported symbols from CL in
> > their downcase counterpart.
>

> If that's really what you want to do, you should probably just use
> Allegro's "modern mode" Lisp which is just like Common Lisp but with
> all the names in COMMON-LISP downcased. They invented this mode as a
> solution to the kind of problem you are dealing with.

Yes. In fact it is the solution i was looking for in others cl lisp
implementations. Others not having restrictions ;-) 900 euros is not cheap
for personal usage.

> On the other hand you can probably also come up with a less painful
> solution in portable Common Lisp by using a readtable-case of
> :preserve or :invert.

No it is not sufficient. You may use :preserve to read code which doesn't
include CL symbols. But it doesn't solve the problem when you include them
in the same forms (or you have to type them UPPERCASE).

See the example i have given in an other post.

--

Marco Antoniotti

unread,
Oct 14, 2004, 7:09:10 PM10/14/04
to

Christophe Turle wrote:

> "Pascal Costanza" <cost...@web.de> a écrit dans le message de
> news:ckm9bt$uf0$1...@f1node01.rhrz.uni-bonn.de...


>
>>Christophe Turle wrote:
>>
>>
>>>I want to change a symbol name. But it is an error to do that, why ?
>>>

>>>(setf (symbol-name 'myfunc) "myFunct")
>>>=> attempt to to modify a read-only string: "MYFUNC"
>>>
>>>From the semantic view point, i don't see why it is forbidden. I hope
>
> it's
>
>>>not for performance issue :(
>>>
>>>Is there an easy way to hack this ? I really need this feature.


>>
>>You're calling for deep trouble. (Hint: Symols are part of a program
>>source code.)
>
>
> Symbols are but why their name are ? symbol & name should be distinct.
>
>

>>What is it that you actually want to do?
>
>

> I want to rename all lisp symbols to their downcase counter part. I found
> this way to correct the bad reader uppercase convention : we write symbols
> in lower-case but as mentionned here a few days ago, we still use upper-case
> conversion for backward compatibility :(

It is not "backward compatibility". It is TWTA (The Way Things Are).
:) Sorry. I don't like it either, but that is the way it is.

The way to do that is to define your own package.

(defpackage "MY-CL" (:use))

(do-external-symbols (s "CL")
(let ((new-symbol (intern (string-downcase (symbol-name s)) "MY-CL")))
(when (boundp s)
(setf (symbol-value new-symbol) (symbol-value s)))
(when (fboundp s)
(setf (symbol-function new-symbol) (symbol-function s)))
;; Classes, types and other named entitied should be handled
;; here.
))

It is not perfect, but it is a start.

> The trouble arises when you need to mingle your code with preserve case code
> (like java). You have to use ugly '|' syntax to make all work together. And
> all that overhead because of old choices.

You need READTABLE-CASE :INVERT and *PRINT-CASE* :DOWNCASE at a minimum,
and it still has rough edges.
Apart from that, there are no easy and portable solutions around.

As per the "old choices" they are the standard. Either you change that
(good luck :) ), or you may end up breaking it and making your programs
unportable.

> Note that this is also useful when you change your mind about the name of a
> function, macro, variable or better : something you don't know all sub
> layers ...

Isn't M-% enough? :)

Cheers
--
Marco

Antonio Menezes Leitao

unread,
Oct 14, 2004, 6:18:12 PM10/14/04
to
"Christophe Turle" <ctu...@nospam.com> writes:

> "Jon Boone" <ipmo...@delamancha.org> a écrit dans le message de
> news:m3fz4h5...@spiritus.delamancha.org...
>> "Christophe Turle" <ctu...@nospam.com> writes:
>>
>> > When you can do that it's already too late for cl symbols. They are
> already
>> > in uppercase. So you will have to write them in uppercase and it's what
> i
>> > want to avoid.
>>
>> Ah, then you want the allegro "modern" environment.
>>
>> --jon
>
> It seems.

No, it doesn't.

Read the hyperspec section on readtable-case :invert and also the
section on the effects of the readtable-case on printing.

António Leitão.

Barry Margolin

unread,
Oct 14, 2004, 9:20:34 PM10/14/04
to
In article <416F0FF5...@juno.com>, Jeff Sandys <san...@juno.com>
wrote:

> Symbols are also called atoms, they are suppose to be immutable.

That's a silly answer, since symbols are *not* immutable. They have a
number of attributes that you can change: the value cell, the function
cell, the package, and the property list. The name is the only
attribute that you can't change.

Peter Seibel

unread,
Oct 14, 2004, 5:40:04 PM10/14/04
to
"Christophe Turle" <ctu...@nospam.com> writes:

Actually I meant it as a logical question. For two different fasls to
"contain" the same symbol requires *some* identifying information for
each symbol that can be stored in different fasls, compiled at
different times. In Common Lisp that information is the combination of
symbol name and package.

I'm not saying it's impossible to design a Lisp that allowed for
symbol renaming. What I am saying is that a lot more would change than
you seem to think. And if one were designing such a radically
different Lisp then presumably one could solve the problem you are
having--you don't want to certain names IN ALL UPPERCASE--in the
straightforward way that Allegro's modern mode does.

In the meantime, in the language we have available--Common Lisp--you
can't do what you think you need to do so if you actually want to
solve your problem you'll need to start looking for a different
solution.

-Peter

--
Peter Seibel pe...@javamonkey.com

Lisp is the red pill. -- John Fraser, comp.lang.lisp

Christophe Turle

unread,
Oct 14, 2004, 7:52:05 PM10/14/04
to
"Pascal Bourguignon" <sp...@mouse-potato.com> a écrit dans le message de
news:87k6ttn...@thalassa.informatimago.com...

> "Christophe Turle" <ctu...@nospam.com> writes:
> > Yes, i'm currently trying to wrap all exported symbols from CL in their
> > downcase counterpart.
>
> You could start like this:
>
> (defpackage "common-lisp" (:nicknames "cl") (:use))
> (do-external-symbols (s "COMMON-LISP")
> (let ((scs (intern (string-downcase (symbol-name s)) "common-lisp")))
> (define-symbol-macro scs s)
> (when (fboundp s)
> (setf (symbol-function scs) (symbol-function s)))
> (setf (symbol-plist scs) (symbol-plist s))
> (export scs "common-lisp")))
> (defpackage "common-lisp-user" (:nicknames "cl-user") (:use
"common-lisp"))
> (in-package "common-lisp-user")
> (|defun| |fun| (|a| |b|) (+ |a| |b|))
> (|fun| 5550000 690)
>
> (this won't work as is, I've got some problems with special operators
> or macros it seems).

We have very similar versions !

(defpackage "common-lisp" (:nicknames "cl") (:use))

(defun def-wrapper (new old)
;;(when (boundp ,old-var) (set ,new-var (symbol-value ,old-var)))
;; not sufficient must check for a symbol-macro ...
(when (fboundp old)
(if (or (macro-function old) (special-form-p old))
(def-macro/special-form-wrapper new old)
(def-function-wrapper new old) )))

(defun def-macro/special-form-wrapper (new old)
(eval `(defmacro ,new (&rest args)
`(,',old ,@args) )))

(defun def-function-wrapper (new old)
(eval `(defun ,new (&rest args)
(apply #',old args) )))

(do-external-symbols (old (find-package "CL"))
(let ((new (intern (string-downcase (symbol-name old)) "cl")))
(def-wrapper new old)
(export new "cl") ))

(defpackage "common-lisp-user" (:nicknames "user") (:use "cl"))

(in-package "user")

;; or |*readtable*| ...
(|defvar| *readtable* (|copy-readtable| cl:nil))

;; doesn't work yet. the setf must be handled differently. Tomorrow ...
(|setf| (|readtable-case| *readtable*) :preserve)


> But as you can see, that does not avoid the need to change the
> readtable-case!!!
>
> And once you set the readtable-case as you want, you don't have to
> rename the symbols.
>

yes for sure i have to use readtable-case :preserve


Thx.

Christophe Turle

unread,
Oct 14, 2004, 7:05:29 PM10/14/04
to
"Pascal Costanza" <cost...@web.de> a écrit dans le message de
news:ckmnjt$6it$1...@newsreader2.netcologne.de...

>
> Christophe Turle wrote:
>
> >> Hmmmm. You should probably meditate on how Lisp is going to load a
> >> FASL file that contains code that refer to symbols using their old
> >> names.
> >
> > Perhaps FASL should refer to symbols by other means.
>
> What's your suggestion?

In fact in the same post there was a suggestion to handle the case where
names have not been changed.

So here i suppose you ask me to handle the case where : FASL is compiled,
after that i reload a new image, change some names naming some symbols used
by FASL, and finally loading the FASL.

For me the FASL needs recompilation since image and FASL are no more talking
with the same reference.

> (Thinking about this question _will_ help you see the point, so please
> do it.)
>

I have done it, but i don't see your point. The meta-problem is that you
want to convince me by showing potential implementation troubles. Perhaps
it's hard to do, but sure it's not impossible, after all it's just an
indirection. I see names as properties.

Kaz Kylheku

unread,
Oct 14, 2004, 6:24:08 PM10/14/04
to
"Christophe Turle" <ctu...@nospam.com> wrote in message news:<416ea832$0$543$626a...@news.free.fr>...

> I want to change a symbol name. But it is an error to do that, why ?
>
> (setf (symbol-name 'myfunc) "myFunct")
> => attempt to to modify a read-only string: "MYFUNC"

This is broken. Or perhaps not.

Firstly (symbol-name 'myfunc) is not any of the standard function
forms that serve as places according to 5.1.2.2 Function Call Forms as
Places. Therefore, it must be treated in accordance with 5.1.2.9 Other
Compound Forms as Places.

This section states that ``For any other compound form for which the
operator is a symbol f, the setf form expands into a call to the
function named (setf f).''

Thus the above is equivalent to:

((setf symbol-name) 'myfunc "myFunct")

Assuming that the implementation gets this detail right, it must be
that it actually has a (SETF SYMBOL-NAME) function, as an extension,
and that this function is in fact what is reporting the error, because
it happens to have the semantics of updating the string object
destructively, rather than replacing the name with a new string
object.

Pascal Bourguignon

unread,
Oct 14, 2004, 6:07:42 PM10/14/04
to
"Christophe Turle" <ctu...@nospam.com> writes:
> For you perhaps, but this is not the case of people like me who see symbols
> as concepts. Do you know about "le triangle sémiotique : référent, signifié,
> signifiant".
>
> simpler and in english ;)

>
> - Concepts and names are not the same. One concept may even have different
> names. Else we were all speaking the same language (human ones).
>
> - The name is just a "pointer" to the symbol. A way to reference it.
>
> - you can change a name by an other and your program will still behave the
> same way. If you change a concept from an other, it won't work the same way.

For me, and for the lisp system. The problem is that the lisp system
considers that the _name_ of a symbol _identifies_ the symbol. Of
course, its "address" too (but not the physical address, since it can
change due to copying colletors). Why is it important? Because as
has been said the relationship between the names and the symbol is not
kept only in the symbol-name slots, but also in hash-tables, in symbol
tables, and more importantly, virtually in *compiled* code. That's
why I'm keeping telling you to do it at the _source_ level, with an
editor.

This does not necessarilly means out of the lisp system: you can use
hemlock, or you could have a sexp editor inside your lisp image. With
my clisp example, I underlined the fact that most lisp system don't
keep the source of the functions (some don't even keep the
documentation strings!). So you won't be able to track all
references to a given symbol, be it by name or by pointer, because you
may not have access to the compiled functions or to other data
structures generated and used by the lisp system, disassemble
notwithstanding.

For parts of programs on which the lisp system does not apply any
special meaning(don't generate code and data structures from a
source), you _could_ use symbols in the way you want. For example,
with uninterned symbols, or with symbols interned in a package of your
own not used in program source (as "identifier"), it would not matter
if you renamed them because the lisp system would not have hash-tabled
them or otherwise compiled them. Personnally, I would rather use CLOS
objects for in that case.

> > 1- use an EDITOR!!!
>
> I want to solve this pb with lisp not with externals tools. And i don't see
> how an editor can help me there.


>
> > 2- see SUBST, for example:
> >
> > (subst 'good-name 'bad-name '(defun fun (bad-name other-name)
> > (+ bad-name other-name)))
> >
> > ==> (DEFUN FUN (GOOD-NAME OTHER-NAME) (+ GOOD-NAME OTHER-NAME))
>

> here an example :


>
> (gen-java-code ()
> (let ((modifiers '(public)))
> `(class ,@modifiers Toto) ))
>

> How do you use your subst ? class and public can be subst since they belong
> to a pre-defined set but 'Toto' ?

The important point in my example is the use of quote in front of
(defun fun... : it's considered as data, ie. as a source form.
Later you could:

(eval (subst 'good-name 'bad-name '(defun fun (bad-name other-name)
(+ bad-name other-name))))

to have the lisp system take into account the substitution.

I don't see any difference between class and Toto.

(subst 'foobar toto '(gen-java-code ()
(let ((modifiers '(public)))
`(class ,@modifiers Toto) )))

> > What guarantee do you have that if you substitute in the
> > function-lambda-expression, the change will be applied to the function
> > closure?
>

> Did i say that ? i just proposed :
>
> 1- to change the name of symbols
> 2- to wrap cl variables/functions/macros/special forms with downcase
> symbols.

We must be asking/answering different threads then...

Frode Vatvedt Fjeld

unread,
Oct 14, 2004, 5:48:26 PM10/14/04
to
"Christophe Turle" <ctu...@nospam.com> writes:

> It works because you are not general enough and because you use
> implementation details.

No, it works because I understand the concept of a name in Common Lisp.

> Below is an example showing the advantage of using symbols as
> references.
>
> (defvar *tests* ())
>
> (defmacro def-test (name)
> `(progn
> (defun ,name () (print "i'm a test"))
> (push ',name *tests*) ))
>
> (def-test test1)
>
> [30]> (test1)
> "i'm a test"
> "i'm a test"
>
> [31]> (setf (symbol-function 'test2) (symbol-function 'test1))
> #<CLOSURE TEST1 NIL (DECLARE (SYSTEM::IN-DEFUN TEST1))
> (BLOCK TEST1 (PRINT "i'm a test"))>
>
> [33]> (test2)
> "i'm a test"
> "i'm a test"
>
> [34]> *tests*
> (TEST1)
>
> oops !
>
> Changing the symbol name would have work, whatever the implementation
> details.

Your macro def-test implements the semantics that the variable *test*
will hold a list of names of tests, not a list of tests
(i.e. functions). When you have a list of names, it does not make
sense to "change the name of a name". Write your like this:

... (push (symbol-function ',name) *tests*) ...

and you will have a list of tests. (I am disregarding the issue of
non-symbol function-names for now.) However I don't really know what
problem you are addressing either way.

What you are trying to do is to change the name of a name. That is
just non-sensical.

--
Frode Vatvedt Fjeld

Christophe Turle

unread,
Oct 14, 2004, 7:35:15 PM10/14/04
to
> > Good question but an implementation one (not my cup of tea).
>
> Actually I meant it as a logical question. For two different fasls to
> "contain" the same symbol requires *some* identifying information for
> each symbol that can be stored in different fasls, compiled at
> different times. In Common Lisp that information is the combination of
> symbol name and package.
>
> I'm not saying it's impossible to design a Lisp that allowed for
> symbol renaming.

;)

> What I am saying is that a lot more would change than
> you seem to think.

I'm aware that it would be a big change. But once done, it can be nice.

> And if one were designing such a radically
> different Lisp then presumably one could solve the problem you are
> having--you don't want to certain names IN ALL UPPERCASE--in the
> straightforward way that Allegro's modern mode does.

I've just looked at
http://www.franz.com/support/documentation/6.2/doc/case.htm
and seems that for the same reasons, allegro has developped the modern mode.
Just implementing this on other cl will make me pleased.

> In the meantime, in the language we have available--Common Lisp--you
> can't do what you think you need to do so if you actually want to
> solve your problem you'll need to start looking for a different
> solution.


Yes or use ACL.

Pascal Bourguignon

unread,
Oct 14, 2004, 8:06:51 PM10/14/04
to
"Christophe Turle" <ctu...@nospam.com> writes:
> I've just looked at
> http://www.franz.com/support/documentation/6.2/doc/case.htm
> and seems that for the same reasons, allegro has developped the modern mode.
> Just implementing this on other cl will make me pleased.

Also, clisp has an option for package to be case preserving when
reading their symbols. For example:

(read-from-string "linux:open") ==> LINUX:|open|

You'd have to put your 'Toto in such a package, but you'd have to
either prefix the package: java:Toto

or be inside that package when reading your "java" code, and then
COMMON-LISP symbols will have to be written upper case:

CL-USER> (defpackage "JAVA" (:case-sensitive t) (:use "COMMON-LISP"))
#<PACKAGE JAVA>
CL-USER> (in-package "JAVA")
#<PACKAGE JAVA>
CLISP JAVA> (defvar Toto 5550690)
** - Continuable Error
EVAL: undefined function defvar
If you continue (by typing 'continue'): Retry
The following restarts are also available:
STORE-VALUE :R1 You may input a new value for (FDEFINITION 'defvar).
USE-VALUE :R2 You may input a value to be used instead of (FDEFINITION 'defvar).
ABORT :R3 Abort handling SLIME request.
Break 1 JAVA[4]> :q
; Evaluation aborted
CLISP JAVA> (DEFVAR Toto 5550690)
Toto
CLISP JAVA> Toto
5550690
CLISP JAVA>

Christophe Turle

unread,
Oct 15, 2004, 4:40:23 AM10/15/04
to
"Christophe Turle" <ctu...@nospam.com> a écrit dans le message de
news:416f110b$0$530$626a...@news.free.fr...

;; to handle the setf case and surely others :

(setf (symbol-plist new) (symbol-plist old))

> (when (fboundp old)
> (if (or (macro-function old) (special-form-p old))
> (def-macro/special-form-wrapper new old)
> (def-function-wrapper new old) )))
>
> (defun def-macro/special-form-wrapper (new old)
> (eval `(defmacro ,new (&rest args)
> `(,',old ,@args) )))
>
> (defun def-function-wrapper (new old)
> (eval `(defun ,new (&rest args)
> (apply #',old args) )))
>
> (do-external-symbols (old (find-package "CL"))
> (let ((new (intern (string-downcase (symbol-name old)) "cl")))
> (def-wrapper new old)
> (export new "cl") ))
>
> (defpackage "common-lisp-user" (:nicknames "user") (:use "cl"))
>
> (in-package "user")
>

> ;; or |*readtable*| ...
> (|defvar| *readtable* (|copy-readtable| cl:nil))
>
> ;; doesn't work yet. the setf must be handled differently. Tomorrow ...
> (|setf| (|readtable-case| *readtable*) :preserve)

replaced by :

;; just for testing since it changes the overall reader behavior.
(|setf| (|readtable-case| cl:*readtable*) :preserve)

USER[44]> (defun fun (a b) (+ a b))
fun

USER[48]> (fun 5550000 690)
5550690

USER[49]> (fun 5550000 (1+ 690))
5550691

Ok, this seems fine but in fact we will bump into the wall with
symbol-value.

USER[65]> CL:*PACKAGE*
#<PACKAGE common-lisp-user>

USER[66]> cl:*package*
#<PACKAGE COMMON-LISP-USER>

Damned ! here we can see what i was meaning when writing that symbols denote
more concepts than names. There's really a 'CL:*PACKAGE*' concept. It is not
the name of '#<PACKAGE common-lisp-user>'.


A new solution seems to be the implementation of (name 1-* -> 0-1 symbol)

Hacking 'find-symbol' or 'intern' seems to be a good start, if only 'read'
use them. If it's not the case directly hacking read should work.

Christophe Turle

unread,
Oct 15, 2004, 5:16:03 AM10/15/04
to
"Gareth McCaughan" <gareth.m...@pobox.com> a écrit dans le message de
news:87d5zkj...@g.mccaughan.ntlworld.com...

> Christophe Turle wrote:
>
> [Pascal Bourguignon:]
> > > The essence of a symbol is in its name
> > >, symbols must be distinct from
> > > other symbols. Symbol is one to its name.
>
> [Christophe:]
> > For you perhaps, but this is not the case of people like me who see
symbols
> > as concepts. Do you know about "le triangle sémiotique : référent,
signifié,
> > signifiant".
> ...
> > - Concepts and names are not the same. One concept may even have
different
> > names. Else we were all speaking the same language (human ones).
> >
> > - The name is just a "pointer" to the symbol. A way to reference it.
>
> Indeed, concepts and names are not the same. But concepts and
> symbols are not the same either. Why do you expect symbols to
> behave more like concepts than like names?

I think it is because they were design with this in mind. The property-list
was there to keep concept properties. AI fields used a lot concepts this
way.

> >>> I want to rename all lisp symbols to their downcase counter
> >>> part. I found this way to correct the bad reader uppercase
> >>> convention : we write symbols in lower-case but as mentionned
> >>> here a few days ago, we still use upper-case conversion for
> >>> backward compatibility :(
>
> Well, you want something that Lisp offers no way to do.

i'm not yet sure ;-)

> You'd have the same problem if you were writing in C++
> and wanted a way to make it treat identifiers case-insensitively,
> or if you were writing in Fortran and wanted a way to make it
> dynamically typed.

We are using lisp, don't forget.

> Actually, a better analogy: it's as if
> you were writing in just about any language and wanted to
> replace all its keywords with Japanese translations -- and
> weren't prepared to accept solutions involving macro
> preprocessors, new namespaces, etc.

If i'm using lisp it's because it is self-extensible.

> I happen to think that this restriction imposed by Lisp
> is a reasonable one, and that what you want to do is a
> silly thing to want to do. Presumably you think it's a
> silly restriction, and that what you want to do is reasonable.
> Be all that as it may, you can't do it.

Give me some more time ;)

> Not only because you
> can't change the name of a symbol, but also because you can't
> change the attributes[1] of symbols in the COMMON-LISP package.
>
> [1] I'd say "properties", but that has a more specific
> meaning.
>
> >> Check readtable-case
> >> http://www.lispworks.com/reference/HyperSpec/Body/f_rdtabl.htm
> >
> > It's not sufficient. See example below.
> ...
> > (gen-java-code ()
> > (let ((modifiers '(public)))
> > `(class ,@modifiers Toto) ))
>
> So. You want symbols to be read case-preservingly because
> that fits whatever Java thing you're doing, but you want
> to be able to use the ordinary symbols of CL in lowercase
> because uppercase is so awful. Bad news: the language
> doesn't permit that. You can complain about the language,
> or you can find another mechanism for your Java names.
> How about strings? Or you can use the perfectly adequate
> mechanism Lisp already has for getting arbitrary characters
> into symbol names: |Toto|.

ugly !

> You don't like uppercase letters and you don't like vertical
> bars? Then you can't have what you want.

really not sure yet ;)

> Too bad. You also
> can't make Java case-fold its input and have all its keywords
> changed to upper-case. :-)
>
> *
>
> I've been a bit harsh here. Maybe you have a really good
> reason for wanting to do what you say you want to do. But
> you haven't given one yet; you've just said "I want this"
> and "I want that". Tell us *why* vertical bars, or using
> strings instead of symbols,

ugly.

> or putting the reader in case-invert
> mode and hacking your Lisp-to-Java interface code to invert
> the case of symbols, isn't good enough.

Good idea ! solving a bad by a bad but it seems to work. Thx for the idea i
will keep it and use it if i can't achieve my cl modern mode.

Pascal Costanza

unread,
Oct 15, 2004, 7:10:01 AM10/15/04
to
Barry Margolin wrote:

> To fix this, symbols would have to keep track of all the packages that
> they're interned in, so that they can all be rehashed after you change
> the symbol name.

Including those packages that aren't currently loaded?

> This is not traditionally how packages worked, so it
> was not included in the Common Lisp specification.


Pascal

--
Pascal Costanza University of Bonn
mailto:cost...@web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)

Christophe Turle

unread,
Oct 15, 2004, 4:58:38 AM10/15/04
to
"Thomas F. Burdick" <t...@conquest.OCF.Berkeley.EDU> a écrit dans le message
de news:xcv655c...@conquest.OCF.Berkeley.EDU...

not exactly

MYJAVACONSTANT => myjavaconstant :(

Christophe Turle

unread,
Oct 15, 2004, 4:55:40 AM10/15/04
to
"Antonio Menezes Leitao" <Antonio...@evaluator.pt> a écrit dans le
message de news:873c0hh...@evaluator.pt...


I have read the "modern mode" from allegro site and it seems to be exactly
what i want. I have not seen they use :invert...

Mario S. Mommer

unread,
Oct 15, 2004, 6:08:02 AM10/15/04
to

"Christophe Turle" <ctu...@nospam.com> writes:
> [...deleted...]

Yeah, Mr. Turle, but what happens is that Common Lisp users are a
bunch of backward boneheads trapped in a backyard of computer science,
with an appalling sense of taste, and clearly not up to the task to
understand how revolutionary, no, how *brilliant*, your concept of
semiotic, java compatible, renameble, case insensitive symbol is.

Thank you for being so gracious to inform us.

Pascal Costanza

unread,
Oct 15, 2004, 7:34:43 AM10/15/04
to
Christophe Turle wrote:

> "Pascal Costanza" <cost...@web.de> a écrit dans le message de
> news:ckmnjt$6it$1...@newsreader2.netcologne.de...
>
>>Christophe Turle wrote:
>>
>>>>Hmmmm. You should probably meditate on how Lisp is going to load a
>>>>FASL file that contains code that refer to symbols using their old
>>>>names.
>>>
>>>Perhaps FASL should refer to symbols by other means.
>>
>>What's your suggestion?
>
> In fact in the same post there was a suggestion to handle the case where
> names have not been changed.

That wasn't a suggestion, it was a first rough idea. But before we start
to nitpick about words like "suggestion" ;), let me just say that it is
really problematic to get the details right.

> So here i suppose you ask me to handle the case where : FASL is compiled,
> after that i reload a new image, change some names naming some symbols used
> by FASL, and finally loading the FASL.
>
> For me the FASL needs recompilation since image and FASL are no more talking
> with the same reference.

What about plain old source code that's not loaded yet?

>>(Thinking about this question _will_ help you see the point, so please
>>do it.)
>
> I have done it, but i don't see your point. The meta-problem is that you
> want to convince me by showing potential implementation troubles. Perhaps
> it's hard to do, but sure it's not impossible, after all it's just an
> indirection. I see names as properties.

No, I am not worried about implementation troubles at all. Lisp dialects
are excellent examples that prove that anything that seems twisted first
will eventually be implemented consistently and efficiently when their
users really need it.

No, the deeper problem is really a conceptual problem. Symbols are used
to refer to concepts. You always need pairs of references and referents,
but you are currently suggesting to (potentially) destroy the references
for parties that are interested in keeping them so that they won't be
able to get to the referents anymore. Both source code and compiled code
that are not loaded yet may have references that you cannot easily keep
track of. A translation table, as you suggest it, cannot know whether
some code that is loaded was developed before or after the table was
updated, so this would require a versioning scheme on code. Another
alternative would be to use globally unique identifiers instead (google
for "GUID") so that you really depend on internal IDs. However, that has
the drawback that you can strictly only refer to concepts via such
machine-generated IDs (we are talking about 128 bit hex strings here!)
instead of human memorable names.

However, I also think by now that you really don't want what you're
asking for because the problem of converting between Java and Common
Lisp identifiers has much simpler solutions. Just use a translation
scheme that converts everything to upcase and inserts hyphens before
original uppercase letters. (So, "moveMouse" becomes "MOVE-MOUSE", and
with standard readtable settings you can type "move-mouse".)

Such a conversion potentially has some ambiguities, but it's easy to
signal errors in such cases, and I doubt that they will occur in practice.

Christophe Turle

unread,
Oct 15, 2004, 4:53:04 AM10/15/04
to
"Pascal Bourguignon" <sp...@mouse-potato.com> a écrit dans le message de
news:87655dn...@thalassa.informatimago.com...

let's abstract your code :

(defun substitution (code)
(subst 'foobar 'toto code) ) ; (subst 'class '|class| ...) is ok.

(setq *code* '(gen-java-code ()


(let ((modifiers '(public)))
`(class ,@modifiers Toto) )))

;; if i've made no errors, it should do the same thing.
(substitution *code*)

What i was saying is that the 'substitution' function should be defined only
once for all possible codes. It's why i pointed that it could be done for
java keywords, since i know all of them, but it can't be done for app
specific names like 'toto', else you have to change your body for each app.

Paul Khuong

unread,
Oct 15, 2004, 11:07:20 AM10/15/04
to
"Christophe Turle" <ctu...@nospam.com> wrote in message news:<416f9555$0$29875$626a...@news.free.fr>...

> "Gareth McCaughan" <gareth.m...@pobox.com> a écrit dans le message de
> news:87d5zkj...@g.mccaughan.ntlworld.com...
[...]

> > or putting the reader in case-invert
> > mode and hacking your Lisp-to-Java interface code to invert
> > the case of symbols, isn't good enough.
>
> Good idea ! solving a bad by a bad but it seems to work. Thx for the idea i
> will keep it and use it if i can't achieve my cl modern mode.
How is that bad? Your own idea would mean that things defined before
the synbol name substitution would work differently than those after.
Now, THAT is ugly: an implicit, modal change on something as
fundamental as the behavior of symbols. That is very nearly the
epitome of the misuse of global properties. For example:

(defun foo nil (bar)) ;s0

[change bar to baz] ;c

(defun bar nil blah) ;s1

(defun foo2 nil (bar)) ;s2
(defun foo3 nil (baz)) ;s3

What does changing the symbol of the symbol's data mean? s2 is now
different from s0! Is s3 the same as s0? Is BAR actually not BAR? Is
there a spoon? Not only is the very concept of changing a symbol's
name, its _key_, extremely confusing, but the consequences are far
from clear.

In addition, your way of doing things is even worse, since it makes
the meaning of _symbols_ dependant on time, on the order forms are
evaluated. Now that is ugly, not using a preprocessor, or a macro. At
least, when the madness is clearly scoped by a form, the time factor
is eliminated. Quarantining your special reading needs, rather than
radically affecting the whole environment is clearly much more elegant
and beautiful, and is actually usable and logical. Oh, and, when you
only want to change a function's name, using an editor is clearly the
way to go. You're going to do it anyway.

Paul Khuong

Brian Downing

unread,
Oct 15, 2004, 11:28:35 AM10/15/04
to
In article <416fe9fd$0$29890$626a...@news.free.fr>,
Christophe Turle <ctu...@nospam.com> wrote:
> Damned, it seems you are full right !
>
> > (setf (readtable-case *readtable*) :invert)
>
> > `(java-keyword ,(cons 'javaName 'JAVACST))
> (java-keyword (javaName . JAVACST))
>
>
> And just when my hack was working !!!

Now keep in mind that the symbol-names for:

(java-keyword (javaName . JAVACST))

are actually

("JAVA-KEYWORD" ("javaName" . "javacst"))

In your Java glue you're going to have to re-invert all names that are
either all upper case or all lower case.

Still, this is a far better solution that trying to make a new
common-lisp package with lowercase symbols. Many people tried to
mention :invert in this discussion - I'm glad you decided it would work
for you.

Your hack probably won't work in general for many reasons. For one
example, make-hash-table :test will only accept CL:EQUALP, not your new
cl:equalp. Indeed, I bet this is why Allegro only supports selecting
between ANSI mode and Modern mode by redumping the image - it's such an
incredibly pervasive change.

-bcd
--
*** Brian Downing <bdowning at lavos dot net>

Christophe Turle

unread,
Oct 15, 2004, 12:28:42 PM10/15/04
to
"Pascal Bourguignon" <sp...@mouse-potato.com> a écrit dans le message de
news:87oej4m...@thalassa.informatimago.com...

> "Christophe Turle" <ctu...@nospam.com> writes:
> > USER[65]> CL:*PACKAGE*
> > #<PACKAGE common-lisp-user>
> >
> > USER[66]> cl:*package*
> > #<PACKAGE COMMON-LISP-USER>
> >
> > Damned ! here we can see what i was meaning when writing that symbols
denote
> > more concepts than names. There's really a 'CL:*PACKAGE*' concept. It is
not
> > the name of '#<PACKAGE common-lisp-user>'.
>
> You need to use symbol-macros for all boundp symbols.
>
> (define-symbol-macro new old)
>


Yes ! i was wondering why such a macro was not existing. Next time i will
try to look into hyperspec instead of cltl2 ;)

Thomas A. Russ

unread,
Oct 15, 2004, 1:12:22 PM10/15/04
to
"Christophe Turle" <ctu...@nospam.com> writes:

> If someone has put the symbol name in a hashtable, it is bad design. The key
> should have been the symbol not its representation.

But how do you get a reference to a symbol? How do you find the symbol
to use as the key to your hash table? The reader does this by knowing
how to map a name to a particular symbol, and if you go about changing
this name, then massive confusion results.

Either you have the same name mapping to different symbols, or you have
different names mapping to the same symbol, or perhaps even both.

--
Thomas A. Russ, USC/Information Sciences Institute

Kaz Kylheku

unread,
Oct 15, 2004, 1:41:28 PM10/15/04
to
Jeff Sandys <san...@juno.com> wrote in message news:<416F0FF5...@juno.com>...

> Symbols are also called atoms, they are suppose to be immutable.

The set of Lisp types is exhaustively partitioned into atoms and
conses. Everything that is not a cons is an atom. NIL, a number, a
CLOS object, a vector, etc.

> What you are asking to do is alchemy, changing lead to gold.

Think about how these heavy elements originate in the first place.

Christophe Turle

unread,
Oct 15, 2004, 12:11:29 PM10/15/04
to
"Brian Downing" <see-si...@lavos.net> a écrit dans le message de
news:D0Sbd.132302$He1.12711@attbi_s01...

> In article <416fe9fd$0$29890$626a...@news.free.fr>,
> Christophe Turle <ctu...@nospam.com> wrote:
> > Damned, it seems you are full right !
> >
> > > (setf (readtable-case *readtable*) :invert)
> >
> > > `(java-keyword ,(cons 'javaName 'JAVACST))
> > (java-keyword (javaName . JAVACST))
> >
> >
> > And just when my hack was working !!!
>
> Now keep in mind that the symbol-names for:
>
> (java-keyword (javaName . JAVACST))
>
> are actually
>
> ("JAVA-KEYWORD" ("javaName" . "javacst"))
>
> In your Java glue you're going to have to re-invert all names that are
> either all upper case or all lower case.

I hope no ! I won't use the symbol-name, i will let the printer do the work
for me from the symbols.

> Still, this is a far better solution that trying to make a new
> common-lisp package with lowercase symbols. Many people tried to
> mention :invert in this discussion - I'm glad you decided it would work
> for you.

What makes me change my mind was the "java glue". I was thinking it was
required (so bye bye orthogonality). I had not seen the printing was
considering the :invert.

> Your hack probably won't work in general for many reasons. For one
> example, make-hash-table :test will only accept CL:EQUALP, not your new
> cl:equalp.

If you read/test my hack you will see that cl:equalp is never seen. the new
read function convert it to CL:EQUALP as wanted by the :test.

Brian Downing

unread,
Oct 15, 2004, 4:05:00 PM10/15/04
to
In article <416ff6b3$0$29876$626a...@news.free.fr>,

Christophe Turle <ctu...@nospam.com> wrote:
> > Your hack probably won't work in general for many reasons. For one
> > example, make-hash-table :test will only accept CL:EQUALP, not your new
> > cl:equalp.
>
> If you read/test my hack you will see that cl:equalp is never seen. the new
> read function convert it to CL:EQUALP as wanted by the :test.

Ah, my apologies. But from your hack:

(setf (symbol-function 'read)
(lambda (&rest args)
(let ((x (cl:apply *read-fct* args)))
(if (wrapper-p x)
(wrapped-symb x)
x))))

You were correct in your comment - this is not allowed in conforming
Common Lisp. In SBCL this yields:

------------------------------------------------------------------------
Lock on package COMMON-LISP violated when setting the symbol-function of READ.
[Condition of type SYMBOL-PACKAGE-LOCKED-ERROR]

See also:
SBCL Manual, Package Locks [node]
Common Lisp Hyperspec, 11.1.2.1.2 [section]
------------------------------------------------------------------------

Looking at the CLHS in section 11.1.2.1.2 gives a laundry list of 19
things you are not allowed to do to an external symbol of the
COMMON-LISP package. Number 1 disallows binding or altering its value.

However, it is a rather ingenious (yet disgusting!) hack. :)

Kenny Tilton

unread,
Oct 15, 2004, 10:48:59 AM10/15/04
to

Mario S. Mommer wrote:

> "Christophe Turle" <ctu...@nospam.com> writes:
>
>>[...deleted...]
>
>
> Yeah, Mr. Turle, but what happens is that Common Lisp users are a

> bunch of backward boneheads ....

I was wondering how long it would take the ilias detectors to start
going off. and I believe the preferred term is "savages".

:)

kt

--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

Thomas A. Russ

unread,
Oct 15, 2004, 1:09:19 PM10/15/04
to
"Christophe Turle" <ctu...@nospam.com> writes:

> > You're calling for deep trouble. (Hint: Symols are part of a program
> > source code.)
>
> Symbols are but why their name are ? symbol & name should be distinct.

Because if symbols and their names are distinct, then you lose the
ability to reliably map from symbol names to symbols. That is the
fundamental reason why symbol names cannot be altered. It would be
really bad if the following happened:

(setq a (read-from-string "FOO"))

(setf (symbol-name a) "Foo")

(setq b (read-from-string "FOO"))

(eq a b) => NIL

You want the mapping to be immutable.

Christophe Turle

unread,
Oct 15, 2004, 11:49:31 AM10/15/04
to
"Paul Khuong" <pkh...@gmail.com> a écrit dans le message de
news:a828a711.04101...@posting.google.com...

> "Christophe Turle" <ctu...@nospam.com> wrote in message
news:<416f9555$0$29875$626a...@news.free.fr>...
> > "Gareth McCaughan" <gareth.m...@pobox.com> a écrit dans le message
de
> > news:87d5zkj...@g.mccaughan.ntlworld.com...
> [...]
> > > or putting the reader in case-invert
> > > mode and hacking your Lisp-to-Java interface code to invert
> > > the case of symbols, isn't good enough.
> >
> > Good idea ! solving a bad by a bad but it seems to work. Thx for the
idea i
> > will keep it and use it if i can't achieve my cl modern mode.

> How is that bad?

The idea is good. what is bad is that we write 'foo' and it is change to
'FOO' internaly. It is a hack. Imagine lisp were designed nowdays, i think
cl symbols would be in lowercase. This means, we are not making evolve the
lisp design, we are just hacking it.

> Your own idea would mean that things defined before
> the synbol name substitution would work differently than those after.

Yes.

> Now, THAT is ugly: an implicit, modal change on something as
> fundamental as the behavior of symbols. That is very nearly the
> epitome of the misuse of global properties. For example:
>
> (defun foo nil (bar)) ;s0
>
> [change bar to baz] ;c
>
> (defun bar nil blah) ;s1
>
> (defun foo2 nil (bar)) ;s2
> (defun foo3 nil (baz)) ;s3
>
> What does changing the symbol of the symbol's data mean? s2 is now
> different from s0!

Yes it is.

> Is s3 the same as s0?

Yes.

> Is BAR actually not BAR? Is
> there a spoon? Not only is the very concept of changing a symbol's
> name, its _key_, extremely confusing, but the consequences are far
> from clear.


> In addition, your way of doing things is even worse, since it makes
> the meaning of _symbols_ dependant on time, on the order forms are
> evaluated.

Yes. And i agree that it may be confusing. But not allowing it won't tell us
its usefulness.

> Now that is ugly, not using a preprocessor, or a macro. At
> least, when the madness is clearly scoped by a form, the time factor
> is eliminated. Quarantining your special reading needs, rather than
> radically affecting the whole environment is clearly much more elegant
> and beautiful, and is actually usable and logical.

> Oh, and, when you
> only want to change a function's name, using an editor is clearly the
> way to go. You're going to do it anyway.

One problem is that your old definition is still there.

Marco Antoniotti

unread,
Oct 15, 2004, 1:16:03 PM10/15/04
to

Christophe Turle wrote:
>
>
> I have read the "modern mode" from allegro site and it seems to be exactly
> what i want. I have not seen they use :invert...
>

They don't. Instead they break the ANSI standard.

Seriously. Have you considered creating your own ad hoc CL-LOWERCASE
package? (Pardon the pun :) )

Then you can program in it with READTABLE-CASE set to :PRESERVE.

Cheers
--
Marco

Barry Margolin

unread,
Oct 15, 2004, 10:07:26 PM10/15/04
to
In article <ckob69$12k2$1...@f1node01.rhrz.uni-bonn.de>,
Pascal Costanza <cost...@web.de> wrote:

> Barry Margolin wrote:
>
> > To fix this, symbols would have to keep track of all the packages that
> > they're interned in, so that they can all be rehashed after you change
> > the symbol name.
>
> Including those packages that aren't currently loaded?

If the packages aren't yet loaded, the symbol can't be interned in them.
If you load the package later and intern the name into it, you'll intern
the symbol that has that name at the time you intern.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Christophe Turle

unread,
Oct 16, 2004, 4:44:28 AM10/16/04
to
> You were correct in your comment - this is not allowed in conforming
> Common Lisp. In SBCL this yields:
>
> ------------------------------------------------------------------------
> Lock on package COMMON-LISP violated when setting the symbol-function of
READ.
> [Condition of type SYMBOL-PACKAGE-LOCKED-ERROR]
>
> See also:
> SBCL Manual, Package Locks [node]
> Common Lisp Hyperspec, 11.1.2.1.2 [section]
> ------------------------------------------------------------------------
>
> Looking at the CLHS in section 11.1.2.1.2 gives a laundry list of 19
> things you are not allowed

'undefined'

> to do to an external symbol of the
> COMMON-LISP package. Number 1 disallows binding or altering its value.

Good reference, thx sbcl.

I think it's more :
- 2. Defining, undefining, or binding it as a function.

Now i understand why read is not traceable with clisp :
- 9. Tracing it (via trace).

So these implementations are right but what a pitty all these restrictions.
I hope it will fall one day after all 'undefined' is not 'not allowed' and
corman lisp is a proof it can be done.

Thx for the clarification.

Christophe Turle

unread,
Oct 16, 2004, 4:55:12 AM10/16/04
to
"Thomas A. Russ" <t...@sevak.isi.edu> a écrit dans le message de
news:ymiekjz...@sevak.isi.edu...

> "Christophe Turle" <ctu...@nospam.com> writes:
>
> > > You're calling for deep trouble. (Hint: Symols are part of a program
> > > source code.)
> >
> > Symbols are but why their name are ? symbol & name should be distinct.
>
> Because if symbols and their names are distinct, then you lose the
> ability to reliably map from symbol names to symbols. That is the
> fundamental reason why symbol names cannot be altered. It would be
> really bad if the following happened:
>
> (setq a (read-from-string "FOO"))
>
> (setf (symbol-name a) "Foo")

I think you mean (setf (symbol-name 'FOO) "Foo")
so now a => |Foo|

>
> (setq b (read-from-string "FOO"))
>
> (eq a b) => NIL

Yes and it appears coherent. View these forms as typed form the REPL one by
one. Not in a file (use an editor for this ;) ).

>
> You want the mapping to be immutable.
>

Me ? no ;)

If it was possible you would be able to do more things not less. So in any
case you won't be forced to use it. Of course, implementations have to be
revamped...

Christophe Turle

unread,
Oct 16, 2004, 4:59:36 AM10/16/04
to
"Thomas A. Russ" <t...@sevak.isi.edu> a écrit dans le message de
news:ymid5zj...@sevak.isi.edu...

> "Christophe Turle" <ctu...@nospam.com> writes:
>
> > If someone has put the symbol name in a hashtable, it is bad design. The
key
> > should have been the symbol not its representation.
>
> But how do you get a reference to a symbol? How do you find the symbol
> to use as the key to your hash table? The reader does this by knowing
> how to map a name to a particular symbol, and if you go about changing
> this name, then massive confusion results.

third time :) 'someone' is for 'users'. I know there is the read hashtable.
But i think it is the only one.

> Either you have the same name mapping to different symbols,

No.

> or you have
> different names mapping to the same symbol, or perhaps even both.

Yes. And perhaps it's cool : no more need for abbrev macros for example...

Christophe Turle

unread,
Oct 16, 2004, 5:09:07 AM10/16/04
to
"Marco Antoniotti" <mar...@cs.nyu.edu> a écrit dans le message de
news:nBTbd.13$u5.2...@typhoon.nyu.edu...

>
> Seriously. Have you considered creating your own ad hoc CL-LOWERCASE
> package? (Pardon the pun :) )
>
> Then you can program in it with READTABLE-CASE set to :PRESERVE.

Yes.

As shown in previous posts two ways to accomplish this :

- hacking the reader to wrap the mapping string->symbols.
- redirecting CL-LOWERCASE symbols to their CL counterparts.

But since :invert mode seems to suffice for my problem at hand and is
portable, i keep these for future needs.

--

jayessay

unread,
Oct 16, 2004, 9:44:56 AM10/16/04
to
"Christophe Turle" <ctu...@nospam.com> writes:

> "Thomas A. Russ" <t...@sevak.isi.edu> a écrit dans le message de
> news:ymiekjz...@sevak.isi.edu...
> > "Christophe Turle" <ctu...@nospam.com> writes:
> >
> > > > You're calling for deep trouble. (Hint: Symols are part of a program
> > > > source code.)
> > >
> > > Symbols are but why their name are ? symbol & name should be distinct.
> >
> > Because if symbols and their names are distinct, then you lose the
> > ability to reliably map from symbol names to symbols. That is the
> > fundamental reason why symbol names cannot be altered. It would be
> > really bad if the following happened:
> >
> > (setq a (read-from-string "FOO"))
> >
> > (setf (symbol-name a) "Foo")
>
> I think you mean (setf (symbol-name 'FOO) "Foo")

The symbol FOO is the value of a, so (symbol-name a) == (symbol-name 'foo)

> so now a => |Foo|

No, the value of a is still the same _symbol_, but with a different
UID than before.


> > (setq b (read-from-string "FOO"))
> >
> > (eq a b) => NIL
>
> Yes and it appears coherent.

Actually it appears quite incoherent because you now have two symbols
which originally had the same UID, but now do not. Any time you have
a UID map to different things, you are basically in trouble.

Make sure you get a grip on the fact that the internal id (for the
sake of conversation let's say this is the machine address, i.e., the
thing that eq will compare) is _not_ the UID of the symbols. The UID
is the fully qualified _name_. This is a big deal and you certainly
don't appear to have a grip on it.

You need to have a UID for symbols for things to work. A symbol's UID
needs to be fixed no matter when you encounter _the_ symbol, where you
encounter _the_ symbol, nor the order you encounter _the_ symbol.

You also really really really should have this UID be human readable
and useable, and that is why the fully qualified _name_ is used for
such UIDs in Common Lisp.


> > You want the mapping to be immutable.
> >
>
> Me ? no ;)

That's because you don't understand that the _name_ is the UID.


> If it was possible you would be able to do more things not less.

Presumably you'd also love to have a contradiction lurking in the
foundations of mathematics. Afterall, you can then do _anything_,
which is clearly a _lot_ more than you can if there isn't one.


/Jon

--
'j' - a n t h o n y at romeo/charley/november com

Christophe Turle

unread,
Oct 16, 2004, 5:37:12 PM10/16/04
to
"jayessay" <nos...@foo.com> a écrit dans le message de
news:m3fz4e3...@rigel.goldenthreadtech.com...

> "Christophe Turle" <ctu...@nospam.com> writes:
>
> > "Thomas A. Russ" <t...@sevak.isi.edu> a écrit dans le message de
> > news:ymiekjz...@sevak.isi.edu...
> > > "Christophe Turle" <ctu...@nospam.com> writes:
> > >
> > > > > You're calling for deep trouble. (Hint: Symols are part of a
program
> > > > > source code.)
> > > >
> > > > Symbols are but why their name are ? symbol & name should be
distinct.
> > >
> > > Because if symbols and their names are distinct, then you lose the
> > > ability to reliably map from symbol names to symbols. That is the
> > > fundamental reason why symbol names cannot be altered. It would be
> > > really bad if the following happened:
> > >
> > > (setq a (read-from-string "FOO"))
> > >
> > > (setf (symbol-name a) "Foo")
> >
> > I think you mean (setf (symbol-name 'FOO) "Foo")
>
> The symbol FOO is the value of a, so (symbol-name a) == (symbol-name 'foo)
>
> > so now a => |Foo|
>
> No, the value of a is still the same _symbol_, but with a different
> UID than before.

If it was really what you meant, you will be on trouble later. Let's see why
:

Let's take the notation [symbol-name symbol symbol-value]

>> (setq a (read-from-string "FOO")) is like :

(setq ["A" a unbound] ["FOO" foo unbound])
=> ["A" a ["FOO" foo unbound]]

>> (setf (symbol-name a) "Foo") is like :

(setf (symbol-name ["A" a ["FOO" foo unbound]]) "Foo")
=> ["Foo" a ["FOO" foo unbound]]

>> (setq b (read-from-string "FOO")) is like :

(setq ["B" b unbound] ["FOO" foo unbound])
=> ["B" b ["FOO" foo unbound]]

now you are on trouble since there's no symbol named "A"

>>> (eq a b) is like :

(eq ["A" a2 unbound] ["B" b ["FOO" foo unbound]])
=> error : A is unbound

and not

>> => NIL

Pascal Bourguignon

unread,
Oct 16, 2004, 6:28:32 PM10/16/04
to
"Christophe Turle" <ctu...@nospam.com> writes:

> I want to change a symbol name. But it is an error to do that, why ?
>
> (setf (symbol-name 'myfunc) "myFunct")
> => attempt to to modify a read-only string: "MYFUNC"
>
> From the semantic view point, i don't see why it is forbidden. I hope it's
> not for performance issue :(
>
> Is there an easy way to hack this ? I really need this feature.

What you are missing IMO, is that the data structure used to store
symbols are merely implementation details. A lisp system would be as
valid if it did not had a "symbol table", and used only names. You
would still have a functions table and a values table and a plisp
table, they would merely map directly symbol name strings to function,
values or plist.

function table:
"COMMON-LISP:+" --> <primitive:+>
"COMMON-LISP-USER:FACT" --> ("COMMON-LISP:LAMBDA" ("COMMON-LISP-USER:FACT")
("COMMON-LISP:IF"
("COMMON-LISP:<" 0 "COMMON-LISP-USER:FACT")
("COMMON-LISP-USER:FACT"
("COMMON-LISP:*"
"COMMON-LISP-USER:FACT"
("COMMON-LISP-USER:FACT"
("COMMON-LISP:1-"
"COMMON-LISP-USER:FACT"))))
1))
value table:
"COMMON-LISP-USER:FACT" --> ("COMMON-LISP-USER:\""
"COMMON-LISP-USER:HAL" "COMMON-LISP-USER:IS"
"COMMON-LISP-USER:AN" "COMMON-LISP-USER:AI"
"COMMON-LISP-USER:\"" "COMMON-LISP-USER:IS"
"COMMON-LISP-USER:A" "COMMON-LISP-USER:FACT")

Which shows you that to change the name, you'd have to scan the whole
system to find names inside existing functions and data, and to
determine whether you really want to change the name or not: do you
really want to change a dynamic variable or a function when you're
renaming the symbol used for a lexical binding?

There's a reason why the first LISPs did not have a string type!

--
__Pascal Bourguignon__ http://www.informatimago.com/

Voting Democrat or Republican is like choosing a cabin in the Titanic.

Vassil Nikolov

unread,
Oct 17, 2004, 10:43:18 PM10/17/04
to
"Christophe Turle" <ctu...@nospam.com> writes:

> [...]


> Imagine lisp were designed nowdays, i think
> cl symbols would be in lowercase.

Would it then have (by default) a case-insensitive but downcasing
reader, or a case-sensitive one?

---Vassil.


--
Vassil Nikolov <vnik...@poboxes.com>

Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.

Vassil Nikolov

unread,
Oct 17, 2004, 10:45:48 PM10/17/04
to
"Christophe Turle" <ctu...@nospam.com> writes:

>> [...]


>> Looking at the CLHS in section 11.1.2.1.2 gives a laundry list of 19
>> things you are not allowed
>
> 'undefined'

That still means "not allowed", but without a guarantee that every
attempt at breaking the rules will be caught.

Vassil Nikolov

unread,
Oct 17, 2004, 10:47:54 PM10/17/04
to
jayessay <nos...@foo.com> writes:

> [...]


> Presumably you'd also love to have a contradiction lurking in the
> foundations of mathematics. Afterall, you can then do _anything_

Or perhaps, "prove anything, and do nothing"...

Christophe Turle

unread,
Oct 18, 2004, 3:16:52 AM10/18/04
to
"Vassil Nikolov" <vnik...@poboxes.com> a écrit dans le message de
news:lz8ya42...@janus.vassil.nikolov.names...

> "Christophe Turle" <ctu...@nospam.com> writes:
>
> > [...]
> > Imagine lisp were designed nowdays, i think
> > cl symbols would be in lowercase.
>
> Would it then have (by default) a case-insensitive but downcasing
> reader, or a case-sensitive one?

case-sensitive.

--

___________________________________________________________
Christophe Turle.
(format nil "~S@~S.~S" 'c.turle 'wanadoo 'fr)

sava preview : http://perso.wanadoo.fr/turle/lisp/sava.html
XP hack for Clisp : http://perso.wanadoo.fr/turle/lisp/xp.html


Marco Antoniotti

unread,
Oct 18, 2004, 11:04:03 AM10/18/04
to

Vassil Nikolov wrote:
> "Christophe Turle" <ctu...@nospam.com> writes:
>
>
>>[...]
>>Imagine lisp were designed nowdays, i think
>>cl symbols would be in lowercase.
>
>
> Would it then have (by default) a case-insensitive but downcasing
> reader, or a case-sensitive one?

I'd bet it would have a case sensitive reader.

Cheers
--
Marco

jayessay

unread,
Oct 18, 2004, 1:26:28 PM10/18/04
to
Vassil Nikolov <vnik...@poboxes.com> writes:

> jayessay <nos...@foo.com> writes:
>
> > [...]
> > Presumably you'd also love to have a contradiction lurking in the
> > foundations of mathematics. Afterall, you can then do _anything_
>
> Or perhaps, "prove anything, and do nothing"...

I like that better, and it is even more apropos to the context...

Thomas A. Russ

unread,
Oct 18, 2004, 5:44:57 PM10/18/04
to
"Christophe Turle" <ctu...@nospam.com> writes:

>
> "Thomas A. Russ" <t...@sevak.isi.edu> a écrit dans le message de
> news:ymid5zj...@sevak.isi.edu...
> > "Christophe Turle" <ctu...@nospam.com> writes:
> >
> > > If someone has put the symbol name in a hashtable, it is bad design. The
> key
> > > should have been the symbol not its representation.
> >
> > But how do you get a reference to a symbol? How do you find the symbol
> > to use as the key to your hash table? The reader does this by knowing
> > how to map a name to a particular symbol, and if you go about changing
> > this name, then massive confusion results.
>
> third time :) 'someone' is for 'users'. I know there is the read hashtable.
> But i think it is the only one.
>
> > Either you have the same name mapping to different symbols,
>
> No.

Really? What magic accomplishes this?

Suppose we create a symbol S1 with name "FOO" and then create another
symbol S2 with name "Foo".

Then we change the name of S1 to be "Foo" as well.

If we then want the symbol named "Foo", which one do we get? S1 or S2?

The whole point of interned symbols in lisp is that there is an
unambiguous mapping from fully-qualified names to symbols.

(Because of import and its ilk, there may in fact be multiple fully
qualified names that map to the same symbol using different package
prefixes, but the name part is fixed.)

Hmmm, I just had a thought. If you don't want to have the names of
symbols map to the symbols, perhaps what you really want are uninterned
symbols. I somehow don't think this is really what you want, but I
don't see how else you can assure that you get the symbol you want when
you or anyone else can change the mapping from the text representation
at will.

> > or you have
> > different names mapping to the same symbol, or perhaps even both.
>
> Yes. And perhaps it's cool : no more need for abbrev macros for
> example...

--

Vassil Nikolov

unread,
Oct 19, 2004, 1:11:16 AM10/19/04
to
"Christophe Turle" <ctu...@nospam.com> writes:

> "Vassil Nikolov" <vnik...@poboxes.com> a écrit dans le message de
> news:lz8ya42...@janus.vassil.nikolov.names...
>> "Christophe Turle" <ctu...@nospam.com> writes:
>>
>> > [...]
>> > Imagine lisp were designed nowdays, i think
>> > cl symbols would be in lowercase.
>>
>> Would it then have (by default) a case-insensitive but downcasing
>> reader, or a case-sensitive one?
>
> case-sensitive.

I much prefer case-insensitive names by default [1] (of course, it
is important to have the option of case-sensitive names, but only if
explicitly requested). I believe it is important to be "culturally
compatible" with (certain) natural languages, when it comes to the
question whether two names are different, if they only differ in
their letter case. (Yes, I know that there are many who believe
otherwise.) For example, I feel much more comfortable to know that

(defun foo (...) ...)
(defun Foo (...) ...)
(defun FOO (...) ...)

won't define three different functions. Another example, from Java,
a case-sensitive language, is the way a couple of names such as
javax.servlet.http.HttpServletResponse.encodeUrl were deprecated
(the latter in favor of encodeURL) just because the authors didn't
get the case right the first time. (And is it really consistent to
have "Http" but "URL" in various names?)

---Vassil.

[1] Needless to say, I'm quite used to case-sensitive ones as well...

Christophe Turle

unread,
Oct 19, 2004, 9:58:35 AM10/19/04
to
"Thomas A. Russ" <t...@sevak.isi.edu> a écrit dans le message de
news:ymibrez...@sevak.isi.edu...

> "Christophe Turle" <ctu...@nospam.com> writes:
>
> >
> > "Thomas A. Russ" <t...@sevak.isi.edu> a écrit dans le message de
> > news:ymid5zj...@sevak.isi.edu...
> > > "Christophe Turle" <ctu...@nospam.com> writes:
> > >
> > > > If someone has put the symbol name in a hashtable, it is bad design.
The
> > key
> > > > should have been the symbol not its representation.
> > >
> > > But how do you get a reference to a symbol? How do you find the
symbol
> > > to use as the key to your hash table? The reader does this by knowing
> > > how to map a name to a particular symbol, and if you go about changing
> > > this name, then massive confusion results.
> >
> > third time :) 'someone' is for 'users'. I know there is the read
hashtable.
> > But i think it is the only one.
> >
> > > Either you have the same name mapping to different symbols,
> >
> > No.
>
> Really? What magic accomplishes this?
>
> Suppose we create a symbol S1 with name "FOO" and then create another
> symbol S2 with name "Foo".

ok: ["FOO" S1] and ["Foo" S2]

> Then we change the name of S1 to be "Foo" as well.

(setf (symbol-name 'FOO) "Foo")
=> error the name "Foo" is already assigned to a symbol.

> If we then want the symbol named "Foo", which one do we get? S1 or S2?
>
> The whole point of interned symbols in lisp is that there is an
> unambiguous mapping from fully-qualified names to symbols.

My proposition is ( name 1-* <-> 0-1 symbol ) so name -> symbol is non
ambigous.

> Hmmm, I just had a thought. If you don't want to have the names of
> symbols map to the symbols, perhaps what you really want are uninterned
> symbols. I somehow don't think this is really what you want, but I
> don't see how else you can assure that you get the symbol you want when
> you or anyone else can change the mapping from the text representation
> at will.

Your 'at will' is strong. It means we will do that over and over confusing
every one reading your code. I'm just seeing this as a 'sometime used/useful
feature'.

--
___________________________________________________________
Christophe Turle.
http://perso.wanadoo.fr/turle/lisp/utilities.html
(format nil "~a@~a.~a" 'c.turle 'wanadoo 'fr)


jayessay

unread,
Oct 19, 2004, 11:39:51 AM10/19/04
to
Vassil Nikolov <vnik...@poboxes.com> writes:

> I much prefer case-insensitive names by default [1] (of course, it
> is important to have the option of case-sensitive names, but only if
> explicitly requested).

I agree, general default case sensitivity is just plain nasty. What I
think would cover most needs and desires is to have
case-insensitive+case-preserving as the default.

0 new messages