"Peter Seibel" <·····@javamonkey.com> a �crit dans le message de
···················@javamonkey.com...
> "Christophe Turle" <······@nospam.com> writes:
>
> > "Peter Seibel" <·····@javamonkey.com> a �crit dans le message de
> > ···················@javamonkey.com...
> >> "Christophe Turle" <······@nospam.com> writes:
> >>
> >> > "Frode Vatvedt Fjeld" <······@cs.uit.no> a �crit dans le message de
> >> > ···················@vserver.cs.uit.no...
> >> >> "Christophe Turle" <······@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.
--
___________________________________________________________
Christophe Turle.
(format nil ···@~S.~S" 'c.turle 'wanadoo 'fr)
sava preview : http://perso.wanadoo.fr/turle/lisp/sava.html
"Christophe Turle" <······@nospam.com> writes:
> "Peter Seibel" <·····@javamonkey.com> a �crit dans le message de
> ···················@javamonkey.com...
>> "Christophe Turle" <······@nospam.com> writes:
>>
>> > "Peter Seibel" <·····@javamonkey.com> a �crit dans le message de
>> > ···················@javamonkey.com...
>> >> "Christophe Turle" <······@nospam.com> writes:
>> >>
>> >> > "Frode Vatvedt Fjeld" <······@cs.uit.no> a �crit dans le message de
>> >> > ···················@vserver.cs.uit.no...
>> >> >> "Christophe Turle" <······@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).
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 ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
> > 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.
--
___________________________________________________________
Christophe Turle.
(format nil ···@~S.~S" 'c.turle 'wanadoo 'fr)
sava preview : http://perso.wanadoo.fr/turle/lisp/sava.html
"Christophe Turle" <······@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>
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
"Pascal Costanza" <········@web.de> a �crit dans le message de
·················@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.
--
___________________________________________________________
Christophe Turle.
(format nil ···@~S.~S" 'c.turle 'wanadoo 'fr)
sava preview : http://perso.wanadoo.fr/turle/lisp/sava.html
Christophe Turle wrote:
> "Pascal Costanza" <········@web.de> a �crit dans le message de
> ·················@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.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)