Hi,
with all the recent discussion regarding case in Common Lisp, I was
wondering...
Suppose there were a function, #'(setf symbol-name). Then something
very trivial like:
(loop
for sym being the external-symbols of (find-package 'cl)
for name = (symbol-name sym)
do (setf (symbol-name sym) (string-downcase name)))
The next thing we'd do is to set the readtable-case to :preserve.
Then, you'd be expected to know to type in lower-case. Otherwise, you
can set the readtable-case to :downcase, if you wanted to still be
able to read other code that assumed that CL was case-insensitive
upper. Basically, you've inverted everything, except *print-case*.
Since *print-case* seems to depend on the value of the current
readtable's case, you don't get the funny escaping stuff
readtable-case is set to :preserve.
Since the :invert switch only affects non-mixed-case symbols, I see
this as yet another useful way to handle the default upper-case mode
nicely. But it still doesn't work in terms of interfacing with other
languages, specifically because pure lowercase symbols in the other
language would have to be written as pure upper-case symbols in Common
Lisp. The mixed-case stuff would work, but not the pure-case
stuff...
UNLESS the _code_ from the other language were also ``read'' with the
:invert flag on readtable-case. Just think about it:
o Symbols in the Common-Lisp package are uppercase.
o with readtable-case :invert, you can write lower-case code, and it
gets inverted. Just stay away from mixed- and upper-case symbols
when referring to stuff in the :cl package.
o interpret the foreign symbols (e.g. from Java) with the same
(i.e. :invert) flag. That way, the mixed-case stuff is the same,
their pure lower-case symbols are converted to upper-case, but SO
ARE YOURS (same goes for their upper-case symbols being convernted
to lower-case). So in the end, everything works out as long as:
1. You use :invert as your readtable-case
2. you don't use mixed-case or upper-case stuff in any of _your_
code. Of course, when you read ``ancient'' CL stuff, you'd use the
standard readtable, along with its case.
I'd still like to hear what people think about the existence of
#'(setf symbol-name) though.
dave
In article <··············@cadet.dsl.speakeasy.net>, ·····@alum.mit.edu says...
> I'd still like to hear what people think about the existence of
> #'(setf symbol-name) though.
symbols are usually stored in packages which are
equivalent to #'equal
hash tables where the keys are the symbol-names
of the symbols. If you change the symbol-name
of a symbol then you may have to rehash it
in the package symbol table.
[in acl we use a case-insensitive string hash function
here so that we can change the case of symbol-names
and not have to rehash].
John Foderaro <···@unspamx.franz.com> writes:
> In article <··············@cadet.dsl.speakeasy.net>, ·····@alum.mit.edu says...
> > I'd still like to hear what people think about the existence of
> > #'(setf symbol-name) though.
>
> symbols are usually stored in packages which are
> equivalent to #'equal
> hash tables where the keys are the symbol-names
> of the symbols. If you change the symbol-name
> of a symbol then you may have to rehash it
> in the package symbol table.
yes. that's my exact point. It's that the setf function would do
that side-effect, and whatever else needs to happen for the symbol's
name to change.
dave
In article <··············@cadet.dsl.speakeasy.net>,
David Bakhash <·····@alum.mit.edu> wrote:
>John Foderaro <···@unspamx.franz.com> writes:
>
>> In article <··············@cadet.dsl.speakeasy.net>, ·····@alum.mit.edu says...
>> > I'd still like to hear what people think about the existence of
>> > #'(setf symbol-name) though.
>>
>> symbols are usually stored in packages which are
>> equivalent to #'equal
>> hash tables where the keys are the symbol-names
>> of the symbols. If you change the symbol-name
>> of a symbol then you may have to rehash it
>> in the package symbol table.
>
>yes. that's my exact point. It's that the setf function would do
>that side-effect, and whatever else needs to happen for the symbol's
>name to change.
It's not really feasible for the SETF function to do that. It would have
to find *every* package in which the symbol is interned and re-hash it.
And if the symbol is external in any of those packages, it would also have
to follow their USE-PACKAGE inheritance trees, to see if this would cause a
conflict.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@genuity.net> writes:
> It's not really feasible for the SETF function to do that. It would have
> to find *every* package in which the symbol is interned and re-hash it.
> And if the symbol is external in any of those packages, it would also have
> to follow their USE-PACKAGE inheritance trees, to see if this would cause a
> conflict.
good! I don't care, because it's not my problem.
My point is that if someone decided to actually make use of
#'(setf symbol-name), then they can start out, first thing, by doing
this work, and then setting readtable-case to :preserve. There's
always DO-ALL-SYMBOLS, right?
The only reason it had appeal to me is that it doesn't directly
_break_ anything (though I still very much dislike this solution).
Adding a function that wasn't there before, to me, seems like an
extension. Presumably, Franz would put that function in the EXCL
package, and implement it. I dunno. I was merely suggesting it as a
possible way to appease people's needs without adding something the
the :common-lisp package, and without modifying anything I depend on
in that package (e.g. #'(setf readtable-case), default startup values,
etc.)
that's all. It's not always a good idea to toss out a proposal.
Though I'm not a big fan of this one, I believe it should be looked
into as a possible way to achieve what people want. I openly state
that I DON'T want the internal case of symbols in the :cl package to
be lowercase; I want them to remain as they are. I _don't_ want
readtable-case to be broken, and I don't want anyone shipping a CL
implementation that's intentionally non-conforming in _any_ way that's
not for a damn good reason (including that the bug is still being
worked on, due to limited resources). This bug with Franz has been in
the queue since what? April? I think that if they felt that it was
important, they'd have fixed it by now. I recall that Erik has even
sent them a patch.
dave
David Bakhash <·····@alum.mit.edu> writes:
> with all the recent discussion regarding case in Common Lisp, I was
> wondering...
>
> Suppose there were a function, #'(setf symbol-name). [...etc.]
The answer is that this isn't a change that only affects certain packages.
All loaded packages are going to see the effect of the various changes you
propose, and there's no guarantee that you won't break assumptions built
into code because it's guaranteed in the spec that the answer from SYMBOL-NAME
won't be the one you're changing things to, etc.
Common Lisp, like it or not, is a reflective/introspective language. It is
capable of noting its own internal structural changes. A correct solution to
this involves the consing of new objects (e.g., new readtables) and new
packages (e.g., packages of tools that work around the problem, or that package
up facilities to help work around it); no existing code will make assumptions
about such new functionality. A correct solution is not to make a visible and
inspectable change to datastructures specified by the standard to have certain
qualities that the visible and inspectable change is designed to void.
Kent M Pitman <······@world.std.com> writes:
> > Suppose there were a function, #'(setf symbol-name). [...etc.]
>
> The answer is that this isn't a change that only affects certain
> packages. All loaded packages are going to see the effect of the
> various changes you propose, and there's no guarantee that you won't
> break assumptions built into code because it's guaranteed in the
> spec that the answer from SYMBOL-NAME won't be the one you're
> changing things to, etc.
I think you might have missed my point. I wanted to do that step of
changing the symbol names FIRST THING--before loading _any_ other
packages.
Then, when the other packages are loaded, they can work, with some
minor prerequsites about the way they're written. But that wasn't my
point, anyway. My point was to try to suggest and understand a
possible way to get a lower-case-based COMMON-LISP package, and
nothing more, but by *adding* something to the spec rather than
changing it.
> Common Lisp, like it or not, is a reflective/introspective language.
> It is capable of noting its own internal structural changes. A
> correct solution to this involves the consing of new objects (e.g.,
> new readtables) and new packages (e.g., packages of tools that work
> around the problem, or that package up facilities to help work
> around it); no existing code will make assumptions about such new
> functionality. A correct solution is not to make a visible and
> inspectable change to datastructures specified by the standard to
> have certain qualities that the visible and inspectable change is
> designed to void.
I agree completely. And I would never use such a hack as I suggested
on one of my packages. But no matter what I do in _my_ packages, it's
the COMMON-LISP package that we're all deeply concerned with. But
yes; I don't like changing *anything* in the CL package; that's the
stuff I like to depend on, even if my stuff is broken. In fact, when
CL-USER gets all confused with symbol clashes and crap after a
listener has been up for a while and I've lost track of what I've put
in there, I like to depend again on the :cl package to make me a new
one that uses it, and start fresh. That way, a particular running
Lisp hardly ever gets corrupted; just certain packages, which you can
remove and re-load, etc. I try not to mess with :cl-user either, but
find myself running into problems when I (:use :cl-user), which of
course I only do for hacking in the listener.
dave