Hi,
One reason why Allegro Common Lisp has introduced modern mode is that
with the current default semantics of interning of strings to symbols,
integration with the Unicode world is hard. However, modern mode also
creates incompatibilities with legacy Common Lisp code.
Here is an attempt to resolve these two issues with a simple metaobject
protocol for packages.
The idea is this: Under this proposal, for each package there is a
corresponding class that represents this package. Classes that represent
packages are in general anonymous (they cannot be found by find-class)
and they are subclasses of the default ANSI Common Lisp class 'symbol.
So for example, the package "COMMON-LISP" is represented by a different
class than the class that represents "COMMON-LISP-USER", and both are
different from the class that represents "KEYWORD", and so on. Whenever
a new package is defined, a new class representation is implicitly
created which is again anonymous and a subclass of the class 'symbol.
The class metaobject that represents a package can be retrieved from a
package object via package-class.
Symbols which are interned in a particular package are direct instances
of the class that represents that package. Uninterned symbols are direct
instances of the class 'symbol.
A function search-symbol is introduced that behaves similar to
find-symbol, except that the string that it is passed is understood to
be unmodified, as read for example from source code. Search-symbol in
turn calls search-symbol-using-class. Here is how search-symbol could be
implemented, modulo error handling:
(defun search-symbol (string &optional (package *package*))
(search-symbol-using-class
(package-class (find-package package))
(find-package package)
string))
The function search-symbol-using-class is a generic function with one
default method. The default behavior is to turn the string into
uppercase and call find-symbol:
(defgeneric search-symbol (package-class package string)
(:method ((package-class symbol) package string)
(find-symbol package (string-upcase string))))
Whenever the reader reads a symbol with an explicit package designator,
search-symbol is called with an unchanged string. So for example,
cl:symbol leads to a call of (search-symbol "symbol" "CL"). In other
words, the first parameter does not depend on the setting of readtable-case.
A corresponding protocol for intern-symbol and intern-symbol-using-class
(as a replacement for intern) is probably also needed.
This protocol allows to express the following:
(defpackage :my-package ...)
(defmethod search-symbol-using-class
"Symbols in my-package are not upped."
((package (eql (package-class (find-package :my-package))))
package string)
(find-symbol string package))
(defmethod intern-symbol-using-class
"Symbols in my-package are not upped."
((package (eql (package-class (find-package :my-package))))
package string)
(intern string package))
Another nice side effect of this proposal would be that the following
method definition would become legal:
(defmethod some-method ((symbol (eql 'my-symbol)))
...)
...in case 'my-symbol is from one of my packages. Since the packages are
of different classes, there is no danger of stepping on each others toes
anymore.
This proposal is only a sketch, I have probably overlooked important
details, but maybe this sounds useful enough to some people so that it's
worthwhile to work this out in more detail.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza wrote:
> Hi,
>
> One reason why Allegro Common Lisp has introduced modern mode is that
> with the current default semantics of interning of strings to symbols,
> integration with the Unicode world is hard. However, modern mode also
> creates incompatibilities with legacy Common Lisp code.
I always thought that 'modern mode' has been introduced for integration
with case-sensitive/case-preserving languages many years ago.
For example you have an external thing which has
the name WindowPointer you can also have another one called
windowPointer.
Now you may want to refer in your Lisp code to these external names
using the normal symbol notation.
(window-hide WindowPointer)
This is only useful if you have case-preserving mode. Since most Lisp
symbols in source code are written in lower case letters, a simple
case preserving reader would make it useful that all Common Lisp
symbols have lower case letters internally. This creates all
kinds of incompatibilities.
I can remember that Allegro CL with the original Next cube already
shipped with this 'modern mode' - because of the Objective-C-based
libraries...
MCL for example uses special reader macros to work around these
issues:
(#_GetScriptManagerVariable #$smSysScript)
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Hi,
>
> One reason why Allegro Common Lisp has introduced modern mode is that
> with the current default semantics of interning of strings to symbols,
> integration with the Unicode world is hard.
Can you explain what the 'Unicode world' is and why
the 'integration' with the 'Unicode world' is 'hard'?
--
http://lispm.dyndns.org/
From: Pascal Costanza
Subject: Re: A simple metaobject protocol for packages
Date:
Message-ID: <4auioiFui9snU1@individual.net>
Rainer Joswig wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> Hi,
>>
>> One reason why Allegro Common Lisp has introduced modern mode is that
>> with the current default semantics of interning of strings to symbols,
>> integration with the Unicode world is hard.
>
> Can you explain what the 'Unicode world' is and why
> the 'integration' with the 'Unicode world' is 'hard'?
Apparently, the mapping between upper case and lower case characters is
not bijective in Unicode. See
http://groups.google.com/group/comp.lang.scheme/browse_frm/thread/4b0928bfe6e93356/30baaa8c88b4a841?hl=en#30baaa8c88b4a841
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Rainer Joswig wrote:
> > In article <··············@individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> >> Hi,
> >>
> >> One reason why Allegro Common Lisp has introduced modern mode is that
> >> with the current default semantics of interning of strings to symbols,
> >> integration with the Unicode world is hard.
> >
> > Can you explain what the 'Unicode world' is and why
> > the 'integration' with the 'Unicode world' is 'hard'?
>
> Apparently, the mapping between upper case and lower case characters is
> not bijective in Unicode. See
> http://groups.google.com/group/comp.lang.scheme/browse_frm/thread/4b0928bfe6e93356/30baaa8c88b4a841?hl=en#30baaa8c88b4a841
>
>
> Pascal
I can't really follow the thread there. Does it matter in any way?
Symbols in Common Lisp are case sensitive. INTERN has no problem
with that.
Only the reader is upcasing symbols by default.
--
http://lispm.dyndns.org/
In article <····························@news-europe.giganews.com>,
Rainer Joswig <······@lisp.de> wrote:
> I can't really follow the thread there. Does it matter in any way?
>
> Symbols in Common Lisp are case sensitive. INTERN has no problem
> with that.
>
> Only the reader is upcasing symbols by default.
I think the problem he's trying to solve is this:
If you use both the reader and INTERN, and you want to get consistent
results, you have to know what kind of case mapping the reader is doing
so you can do the same before calling INTERN.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Pascal Costanza:
> > Can you explain what the 'Unicode world' is and why
> > the 'integration' with the 'Unicode world' is 'hard'?
>
> Apparently, the mapping between upper case and lower case characters is
> not bijective in Unicode. See
Why not restrict case mapping issue only to ASCII?
READ can upcase ASCII chars but treat others as if they
do not have case variation. Most characters do not have
case variants.
From: Pascal Costanza
Subject: Re: A simple metaobject protocol for packages
Date:
Message-ID: <4avmr9Fv1eoaU2@individual.net>
Takehiko Abe wrote:
> Pascal Costanza:
>
>>> Can you explain what the 'Unicode world' is and why
>>> the 'integration' with the 'Unicode world' is 'hard'?
>> Apparently, the mapping between upper case and lower case characters is
>> not bijective in Unicode. See
>
> Why not restrict case mapping issue only to ASCII?
> READ can upcase ASCII chars but treat others as if they
> do not have case variation. Most characters do not have
> case variants.
Sounds like the simplest solution so far. I also don't see any downsides
so far.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza <··@p-cos.net> writes:
> Takehiko Abe wrote:
>> Pascal Costanza:
>>
>>>> Can you explain what the 'Unicode world' is and why
>>>> the 'integration' with the 'Unicode world' is 'hard'?
>>> Apparently, the mapping between upper case and lower case
>>> characters is not bijective in Unicode. See
>> Why not restrict case mapping issue only to ASCII?
>> READ can upcase ASCII chars but treat others as if they
>> do not have case variation. Most characters do not have
>> case variants.
>
> Sounds like the simplest solution so far. I also don't see any
> downsides so far.
I prefer clisp behavior:
'bo�t� --> BO�T�
(vs. the proposed: 'bo�t� --> BO�T� )
--
__Pascal Bourguignon__ http://www.informatimago.com/
READ THIS BEFORE OPENING PACKAGE: According to certain suggested
versions of the Grand Unified Theory, the primary particles
constituting this product may decay to nothingness within the next
four hundred million years.
On Sat, 22 Apr 2006 23:59:02 +0200, Pascal Bourguignon
<···@informatimago.com> tried to confuse everyone with this message:
>Pascal Costanza <··@p-cos.net> writes:
>
>> Takehiko Abe wrote:
>>> Pascal Costanza:
>>>
>>>>> Can you explain what the 'Unicode world' is and why
>>>>> the 'integration' with the 'Unicode world' is 'hard'?
>>>> Apparently, the mapping between upper case and lower case
>>>> characters is not bijective in Unicode. See
>>> Why not restrict case mapping issue only to ASCII?
>>> READ can upcase ASCII chars but treat others as if they
>>> do not have case variation. Most characters do not have
>>> case variants.
>>
>> Sounds like the simplest solution so far. I also don't see any
>> downsides so far.
>
>I prefer clisp behavior:
>
>'bo�t� --> BO�T�
CLISP is pretty good at upcasing characters: it knows Cyrillic, Greek
and various weird letters, like "U with horn and hook above". I
personally don't like that Greek letters are upcased: I can imagine math
application where lowercase and uppercase phi are completely different
functions, and uppercase lambda doesn't evoke associations with
lambda-calculus like lowercase one does. But I guess a person who speaks
Greek language would have a different opinion.
--
|WAR HAS NEVER SOLVED ANYTHING|,----- Timofei Shatrov aka Grue---------.
|(except for ending slavery, ||mail: grue at mail.ru ================ |
| fascism and communism) ||============= http://grue3.tripod.com |
|...and Saddam's dictatorship |`----------------------------------[4*72]
Timofei Shatrov:
> >I prefer clisp behavior:
> >
> >'bo�t� --> BO�T�
>
> CLISP is pretty good at upcasing characters: it knows Cyrillic, Greek
> and various weird letters, like "U with horn and hook above". I
> personally don't like that Greek letters are upcased: I can imagine math
> application where lowercase and uppercase phi are completely different
> functions, and uppercase lambda doesn't evoke associations with
> lambda-calculus like lowercase one does. But I guess a person who speaks
> Greek language would have a different opinion.
I think they are all moot as far as lisp reader is concerned.
Why would anyone wants to type 'bo�t�' in order to get 'BO�T�'?
Is it a function name? Using non-ascii chars for identifiers
is really a bad idea imo. If one wants to use symbols
as data one would use INTERN or reader macro.
I want case insensitive reader, because then I don't have to
memorise function names with case. It is a matter of
convenience. Mapping between A-Z and a-z is enough for that.
····@gol.com (Takehiko Abe) writes:
> Timofei Shatrov:
>
>> >I prefer clisp behavior:
>> >
>> >'bo�t� --> BO�T�
>>
>> CLISP is pretty good at upcasing characters: it knows Cyrillic, Greek
>> and various weird letters, like "U with horn and hook above". I
>> personally don't like that Greek letters are upcased: I can imagine math
>> application where lowercase and uppercase phi are completely different
>> functions, and uppercase lambda doesn't evoke associations with
>> lambda-calculus like lowercase one does. But I guess a person who speaks
>> Greek language would have a different opinion.
>
> I think they are all moot as far as lisp reader is concerned.
> Why would anyone wants to type 'bo�t�' in order to get 'BO�T�'?
Indeed, I'd rather type my programs with capslock, but I'm a fool ;-)
> Is it a function name?
It could be.
> Using non-ascii chars for identifiers
> is really a bad idea imo.
>
> If one wants to use symbols
> as data one would use INTERN or reader macro.
>
> I want case insensitive reader, because then I don't have to
> memorise function names with case. It is a matter of
> convenience. Mapping between A-Z and a-z is enough for that.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"This statement is false." In Lisp: (defun Q () (eq nil (Q)))
From: Thomas A. Russ
Subject: Re: A simple metaobject protocol for packages
Date:
Message-ID: <ymi1wvlvcv2.fsf@sevak.isi.edu>
····@gol.com (Takehiko Abe) writes:
> I think they are all moot as far as lisp reader is concerned.
> Why would anyone wants to type 'bo�t�' in order to get 'BO�T�'?
> Is it a function name? Using non-ascii chars for identifiers
> is really a bad idea imo. If one wants to use symbols
> as data one would use INTERN or reader macro.
>
> I want case insensitive reader, because then I don't have to
> memorise function names with case. It is a matter of
> convenience. Mapping between A-Z and a-z is enough for that.
Hmmm. This actually gives me an idea. Perhaps the semantics of the
:INVERT option to readtable case could be extended as follows for
UniCode support:
Action:
If the symbol name consists solely of lower-case letters a-z and
(optionally) non-alphabetic characters, then upcase the letters.
If the symbol name consists solely of upper-case letters A-Z and
(optionally) non-alphabetic characters, then downcase the letters.
Otherwise leave the characters as is.
The only reason for having the :INVERT option as a readtable case is to
allow one to write the standard Common Lisp symbols in lower-case while
also preserving case distinctions in the symbols. Since none of the
built-in functions use alphabetic characters that are not in the a-zA-Z
range, one can safely leave any symbols with accented or other letters
(such as alpha, aleph, etc.) unconverted. They can use case
preservation.
If there were an update to the standard, perhaps it would be good to
make :INVERT the default readtable case. It would also be useful to
have functions for easy access to the readtable information when
handling symbol names, say something like the following overly? verbose
functions:
INTERN-USING-READTABLE-CASE
SYMBOL-NAME-USING-READTABLE-CASE
which perform the appropriate case conversions.
--
Thomas A. Russ, USC/Information Sciences Institute
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> The function search-symbol-using-class is a generic function with one
> default method. The default behavior is to turn the string into
> uppercase and call find-symbol:
>
> (defgeneric search-symbol (package-class package string)
> (:method ((package-class symbol) package string)
> (find-symbol package (string-upcase string))))
The purpose of this function is totally unclear to me.
Why should I introduce a function that searches for
symbols with just upcased strings? A package can contain
symbols which have names of any case.
Packages don't have a case associated with them in Common Lisp.
It is just that the reader my do some case conversion
when it sees a string and wants to read a symbol. This
conversion is just an effect at read-time. Add that
you can create symbols without using the reader with
any case.
--
http://lispm.dyndns.org/
From: Pascal Costanza
Subject: Re: A simple metaobject protocol for packages
Date:
Message-ID: <4aujraFuqo1gU1@individual.net>
Rainer Joswig wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> The function search-symbol-using-class is a generic function with one
>> default method. The default behavior is to turn the string into
>> uppercase and call find-symbol:
>>
>> (defgeneric search-symbol (package-class package string)
>> (:method ((package-class symbol) package string)
>> (find-symbol package (string-upcase string))))
>
> The purpose of this function is totally unclear to me.
> Why should I introduce a function that searches for
> symbols with just upcased strings? A package can contain
> symbols which have names of any case.
>
> Packages don't have a case associated with them in Common Lisp.
> It is just that the reader my do some case conversion
> when it sees a string and wants to read a symbol. This
> conversion is just an effect at read-time. Add that
> you can create symbols without using the reader with
> any case.
I know.
The use case is this: Most libraries are written using the default
readtable which turns all symbols into upper case. Now assume that you
want to write your own source code using Unicode but still want to use
those libraries (including what's exported from common-lisp).
Readtable-case :invert doesn't help because the mapping between lower
case and upper case characters in Unicode apparently doesn't make a lot
of sense. It seems to me that the only hint that can potentially be used
to distinguish the different libraries while the reader reads source
code is the package that a symbol stems from.
Another use case, if I understand the Franz guys correctly, is to read
XML files as s-expressions, retain the case of characters, but still be
able to interpret the contents as programs. (I am not 100% sure whether
that's what they want.)
I don't claim that my proposal is consistent - I haven't nearly thought
it through in all details. It's just an idea what direction could
potentially be taken without invalidating legacy code.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Rainer Joswig wrote:
> > In article <··············@individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> >> The function search-symbol-using-class is a generic function with one
> >> default method. The default behavior is to turn the string into
> >> uppercase and call find-symbol:
> >>
> >> (defgeneric search-symbol (package-class package string)
> >> (:method ((package-class symbol) package string)
> >> (find-symbol package (string-upcase string))))
> >
> > The purpose of this function is totally unclear to me.
> > Why should I introduce a function that searches for
> > symbols with just upcased strings? A package can contain
> > symbols which have names of any case.
> >
> > Packages don't have a case associated with them in Common Lisp.
> > It is just that the reader my do some case conversion
> > when it sees a string and wants to read a symbol. This
> > conversion is just an effect at read-time. Add that
> > you can create symbols without using the reader with
> > any case.
>
> I know.
>
> The use case is this: Most libraries are written using the default
> readtable which turns all symbols into upper case.
The wording is a bit unprecise for this topic I'd say.
The reader interns some symbols as uppercase (given the default readtable).
foo will be interned as "FOO".
|foo| will be interned as "foo".
and so on.
> Now assume that you
> want to write your own source code using Unicode but still want to use
> those libraries (including what's exported from common-lisp).
> Readtable-case :invert doesn't help because the mapping between lower
> case and upper case characters in Unicode apparently doesn't make a lot
> of sense.
So you want to have a case-sensitive and case-preserving
Unicode reader, Unicode based symbol names and a scheme
to refer to CL standard symbols using this reader?
> It seems to me that the only hint that can potentially be used
> to distinguish the different libraries
'Libraries' are not present in Common Lisp. What do you
want?
> Another use case, if I understand the Franz guys correctly, is to read
> XML files as s-expressions, retain the case of characters, but still be
> able to interpret the contents as programs. (I am not 100% sure whether
> that's what they want.)
This use case is also unclear to me...
--
http://lispm.dyndns.org/
pascal wrote:
>Another use case, if I understand the Franz guys correctly, is to read
>XML files as s-expressions, retain the case of characters, but still be
>able to interpret the contents as programs. (I am not 100% sure whether
>that's what they want.)
if this is the case it seems like it would be usefull to be able to set
some sort of shallow intern so that the symbol table doesn't get
cluttered up over time by bogus or irrelevent tags. also some control
over the mapping between packages and xml namespaces...
Nick
Pascal Costanza <··@p-cos.net> writes:
> Whenever a new package is defined, a new class representation
> is implicitly created which is again anonymous and a subclass
> of the class 'symbol.
>
> The class metaobject that represents a package can be retrieved from a
> package object via package-class.
Because this class is a subclass of SYMBOL, I don't think it can
represent all aspects of a package. So I'd prefer calling the
function PACKAGE-SYMBOL-CLASS.
> Symbols which are interned in a particular package are direct
> instances of the class that represents that package. Uninterned
> symbols are direct instances of the class 'symbol.
The same symbol can be interned in (and exported from) multiple packages.
> Whenever the reader reads a symbol with an explicit package
> designator, search-symbol is called with an unchanged string. So for
> example, cl:symbol leads to a call of (search-symbol "symbol"
> "CL"). In other words, the first parameter does not depend on the
> setting of readtable-case.
But search-symbol and search-symbol-using-class don't use
(readtable-case *readtable*) either, so it won't have any effect.
That breaks compatibility, I think.
How would search-symbol be called when "ext:|O|o\o" is read?
> Another nice side effect of this proposal would be that the following
> method definition would become legal:
>
> (defmethod some-method ((symbol (eql 'my-symbol)))
> ...)
I don't see why it wouldn't be legal now.
(assuming you substitute something for the ellipsis)
From: Pascal Costanza
Subject: Re: A simple metaobject protocol for packages
Date:
Message-ID: <4avnffFvatmnU1@individual.net>
Kalle Olavi Niemitalo wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>> Whenever a new package is defined, a new class representation
>> is implicitly created which is again anonymous and a subclass
>> of the class 'symbol.
>>
>> The class metaobject that represents a package can be retrieved from a
>> package object via package-class.
>
> Because this class is a subclass of SYMBOL, I don't think it can
> represent all aspects of a package. So I'd prefer calling the
> function PACKAGE-SYMBOL-CLASS.
OK.
>> Symbols which are interned in a particular package are direct
>> instances of the class that represents that package. Uninterned
>> symbols are direct instances of the class 'symbol.
>
> The same symbol can be interned in (and exported from) multiple packages.
OK, this probably has to be fixed. Think "each symbol is a direct
instance of the class that represents its home package". (Not sure about
the consequences, though.)
>> Whenever the reader reads a symbol with an explicit package
>> designator, search-symbol is called with an unchanged string. So for
>> example, cl:symbol leads to a call of (search-symbol "symbol"
>> "CL"). In other words, the first parameter does not depend on the
>> setting of readtable-case.
>
> But search-symbol and search-symbol-using-class don't use
> (readtable-case *readtable*) either, so it won't have any effect.
> That breaks compatibility, I think.
>
> How would search-symbol be called when "ext:|O|o\o" is read?
My guess would be "Ooo" - but you're right, this requires more careful
analysis.
>> Another nice side effect of this proposal would be that the following
>> method definition would become legal:
>>
>> (defmethod some-method ((symbol (eql 'my-symbol)))
>> ...)
>
> I don't see why it wouldn't be legal now.
> (assuming you substitute something for the ellipsis)
Ah, sorry. I meant such method definitions on generic functions that are
defined by ANSI Common Lisp, which are illegal according to Section
11.1.2.1.2, item 19 in the HyperSpec.
For example, the following method definition is currently illegal ("the
consequences are undefined"):
(defmethod make-instance ((class (eql 'my-class)) &rest args)
...)
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
From: Christophe Rhodes
Subject: Re: A simple metaobject protocol for packages
Date:
Message-ID: <sqy7xxirm7.fsf@cam.ac.uk>
Pascal Costanza <··@p-cos.net> writes:
> One reason why Allegro Common Lisp has introduced modern mode is that
> with the current default semantics of interning of strings to symbols,
> integration with the Unicode world is hard. However, modern mode also
> creates incompatibilities with legacy Common Lisp code.
>
> Here is an attempt to resolve these two issues with a simple
> metaobject protocol for packages.
> [...]
> This proposal is only a sketch, I have probably overlooked important
> details, but maybe this sounds useful enough to some people so that
> it's worthwhile to work this out in more detail.
Does this proposal come with any reference to the already-implemented
support for backwards-compatible-by-default but extended symbol lookup
semantics present in Common Lisps with historically good Unicode
support? If so, what is the cost of adoption likely to be for those
implementations; if not, why not?
Christophe
On 2006-04-22, Christophe Rhodes <·····@cam.ac.uk> wrote:
> Pascal Costanza <··@p-cos.net> writes:
>> One reason why Allegro Common Lisp has introduced modern mode is
>> that with the current default semantics of interning of strings to
>> symbols, integration with the Unicode world is hard. However,
>> modern mode also creates incompatibilities with legacy Common Lisp
>> code.
>>
>> Here is an attempt to resolve these two issues with a simple
>> metaobject protocol for packages.
>> [...]
>> This proposal is only a sketch, I have probably overlooked
>> important details, but maybe this sounds useful enough to some
>> people so that it's worthwhile to work this out in more detail.
>
> Does this proposal come with any reference to the
> already-implemented support for backwards-compatible-by-default but
> extended symbol lookup semantics present in Common Lisps with
> historically good Unicode support?
<snip>
> if not, why not?
Because Pascal just typed it into his newsreader to see what people'd
think? :)
Does your query imply a request for such a reference, and does such a
request imply a possible interest (negative or positive) in the
proposal? (And if not, why did you even ask? :)
-- Larry
From: Pascal Costanza
Subject: Re: A simple metaobject protocol for packages
Date:
Message-ID: <4av14rFv2s60U1@individual.net>
Christophe Rhodes wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>> One reason why Allegro Common Lisp has introduced modern mode is that
>> with the current default semantics of interning of strings to symbols,
>> integration with the Unicode world is hard. However, modern mode also
>> creates incompatibilities with legacy Common Lisp code.
>>
>> Here is an attempt to resolve these two issues with a simple
>> metaobject protocol for packages.
>> [...]
>> This proposal is only a sketch, I have probably overlooked important
>> details, but maybe this sounds useful enough to some people so that
>> it's worthwhile to work this out in more detail.
>
> Does this proposal come with any reference to the already-implemented
> support for backwards-compatible-by-default but extended symbol lookup
> semantics present in Common Lisps with historically good Unicode
> support? If so, what is the cost of adoption likely to be for those
> implementations; if not, why not?
It doesn't, and this is out of pure ignorance. Where can I find more
information? I don't seem to be able to come up with a good search
string for google to find anything myself.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
From: Christophe Rhodes
Subject: Re: A simple metaobject protocol for packages
Date:
Message-ID: <squ08lilms.fsf@cam.ac.uk>
Pascal Costanza <··@p-cos.net> writes:
> It doesn't, and this is out of pure ignorance. Where can I find more
> information? I don't seem to be able to come up with a good search
> string for google to find anything myself.
Well, Bruno Haible gave a lightning talk in 2004 to the Libre Software
Meeting: some details are at
<http://www-jcsu.jesus.cam.ac.uk/~csr21/papers/lightning/lightning.html>,
section 4. I would imagine that there are more details in the CLISP
implementation documentation.
Christophe
From: Pascal Costanza
Subject: Re: A simple metaobject protocol for packages
Date:
Message-ID: <4avnhvFvatmnU2@individual.net>
Christophe Rhodes wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>> It doesn't, and this is out of pure ignorance. Where can I find more
>> information? I don't seem to be able to come up with a good search
>> string for google to find anything myself.
>
> Well, Bruno Haible gave a lightning talk in 2004 to the Libre Software
> Meeting: some details are at
> <http://www-jcsu.jesus.cam.ac.uk/~csr21/papers/lightning/lightning.html>,
> section 4. I would imagine that there are more details in the CLISP
> implementation documentation.
That solution seems to rely on case inversion which, if I understand
correctly, is problematic in Unicode.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
From: Thomas A. Russ
Subject: Re: A simple metaobject protocol for packages
Date:
Message-ID: <ymimzebudri.fsf@sevak.isi.edu>
Pascal Costanza <··@p-cos.net> writes:
> Christophe Rhodes wrote:
>
> > Meeting: some details are at
> > <http://www-jcsu.jesus.cam.ac.uk/~csr21/papers/lightning/lightning.html>,
> > section 4. I would imagine that there are more details in the CLISP
> > implementation documentation.
>
> That solution seems to rely on case inversion which, if I understand
> correctly, is problematic in Unicode.
Is this really a problem?
I understand that the case conversion for some small set of characters
in Unicode is not 1:1, but will that really cause a problem?
Any Common Lisp solution could specify a canonical case-conversion for
the ambiguous cases, and that would solve the problem.
I'm not aware of which characters have different upper-case verisons,
although I do know of two characters which have a different title-case
version than upper-case.
In any event, why wouldn't a canonical mapping from upper to lower and
lower to upper be impossible to come up with?
How would the ambiguity actually stop code from working?
I suppose that there is the potential for conflicts when using :INVERT
mode in the reader if you have symbols that you want to be distinct, but
which map under case conversion to the same name. Is this really common
enough to worry about? It really would only be an issue if one of the
small set of ambiguous characters is used to distinguish two similar
symbols that are all in a single case. (Because :INVERT only case
converts single-case identifiers. Mixed case identifiers remain the
same).
So, is this really a barrier, or is this more of a theoretical concern
that is unlikely to be a problem in practice?
--
Thomas A. Russ, USC/Information Sciences Institute
Pascal Costanza <··@p-cos.net> writes:
> The class metaobject that represents a package can be retrieved from
> a package object via package-class.
>
> Symbols which are interned in a particular package are direct
> instances of the class that represents that package. Uninterned
> symbols are direct instances of the class 'symbol.
So just to clarify, your proposal fits this model?
(defun class-of (x)
(typecase x
(symbol
(if (not (symbol-package x))
(find-class 'symbol)
(package-class (symbol-package x))))
...))
--
Frode Vatvedt Fjeld
From: Pascal Costanza
Subject: Re: A simple metaobject protocol for packages
Date:
Message-ID: <4avnlaFvatmnU3@individual.net>
Frode Vatvedt Fjeld wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>> The class metaobject that represents a package can be retrieved from
>> a package object via package-class.
>>
>> Symbols which are interned in a particular package are direct
>> instances of the class that represents that package. Uninterned
>> symbols are direct instances of the class 'symbol.
>
> So just to clarify, your proposal fits this model?
>
> (defun class-of (x)
> (typecase x
> (symbol
> (if (not (symbol-package x))
> (find-class 'symbol)
> (package-class (symbol-package x))))
> ...))
Yes. And (package-class (symbol-package x)) is always a subtype of
'symbol (unless x is not a symbol).
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
From: Pascal Costanza
Subject: Re: A simple metaobject protocol for packages
Date:
Message-ID: <4b162gFv1983U1@individual.net>
Pascal Costanza wrote:
> Hi,
>
> One reason why Allegro Common Lisp has introduced modern mode is that
> with the current default semantics of interning of strings to symbols,
> integration with the Unicode world is hard. However, modern mode also
> creates incompatibilities with legacy Common Lisp code.
>
> Here is an attempt to resolve these two issues with a simple metaobject
> protocol for packages.
Hm, this has created more stir that I have expected, and not quite for
the reasons that I have thought of originally.
The idea of my posting was "what can the ideas and idioms in the CLOS
MOP be used for elsewhere", not so much "what is the best solution for
integrating unicode into Common Lisp". It's clear to me how my posting
can be understood in the latter sense, but this wasn't clear to me when
I posted it. Sorry for the confusion.
Having said that, it seems to me that Bruno Haible's discussion of
integration of unicode suggests that a "xyz-using-class" approach would
probably not be enough. But I have to think about this in more detail.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Pascal Costanza wrote:
> > Hi,
> >
> > One reason why Allegro Common Lisp has introduced modern mode is that
> > with the current default semantics of interning of strings to symbols,
> > integration with the Unicode world is hard. However, modern mode also
> > creates incompatibilities with legacy Common Lisp code.
> >
> > Here is an attempt to resolve these two issues with a simple metaobject
> > protocol for packages.
>
> Hm, this has created more stir that I have expected, and not quite for
> the reasons that I have thought of originally.
>
> The idea of my posting was "what can the ideas and idioms in the CLOS
> MOP be used for elsewhere",
Yes, but if you think again - do you think that design makes
sense? For each package a class that does only support
some simple dispatching. As I understood your idea the packages
wouldn't be instances of these classes and the classes would
have symbols as instances. For me it looked like a 'solution' looking
for a problem. Classes that are subclasses of symbol for each
package? Anonymous subclasses of the class symbol? For packages?
That design sounds weird to me. ;-)
Each object has a class depending on the container it belongs to?
When you put an object to a different container, than
you have to change the class of the object? One can
do that with CLOS, but it looks a bit weird...
I'd really prefer simpler designs...
--
http://lispm.dyndns.org/
From: Pascal Costanza
Subject: Re: A simple metaobject protocol for packages
Date:
Message-ID: <4b479tFvlkb2U1@individual.net>
Rainer Joswig wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> Pascal Costanza wrote:
>>> Hi,
>>>
>>> One reason why Allegro Common Lisp has introduced modern mode is that
>>> with the current default semantics of interning of strings to symbols,
>>> integration with the Unicode world is hard. However, modern mode also
>>> creates incompatibilities with legacy Common Lisp code.
>>>
>>> Here is an attempt to resolve these two issues with a simple metaobject
>>> protocol for packages.
>> Hm, this has created more stir that I have expected, and not quite for
>> the reasons that I have thought of originally.
>>
>> The idea of my posting was "what can the ideas and idioms in the CLOS
>> MOP be used for elsewhere",
>
> Yes, but if you think again - do you think that design makes
> sense? For each package a class that does only support
> some simple dispatching. As I understood your idea the packages
> wouldn't be instances of these classes and the classes would
> have symbols as instances. For me it looked like a 'solution' looking
> for a problem. Classes that are subclasses of symbol for each
> package? Anonymous subclasses of the class symbol? For packages?
> That design sounds weird to me. ;-)
Yes, it does. My original idea was that packages are themselves the
classes of which symbols are instances of. I was looking for a
backwards-compatible compromise here, but maybe that was already a step
too far.
> Each object has a class depending on the container it belongs to?
> When you put an object to a different container, than
> you have to change the class of the object? One can
> do that with CLOS, but it looks a bit weird...
I wouldn't want to generalize this idea to other kinds of collections,
although work in that area indeed exists ("environmental acquisition").
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/