sbcl-devel

[The changes are divided in 2 email because the patch is more that 40kb.]
The attached patch changes the code to facilitate a possible future
implementation of modern mode Lisp. Each change is of one of:
. Change SYMBOL to symbol or vice versa.
. Change package designator from string to symbol
. Change (intern "SOME-STRING" "SOME-PACKAGE") to
(intern (symbol-name '#:some-string) '#:some-package)
All trivial changes. Please apply.
Thanks,
Marco

[The changes were divided in 2 email because the patch is more that
40kb, but even that was not enough. It is actually devided in three
parts. They can be applied in any order.]
The attached patch changes the code to facilitate a possible future
implementation of modern mode Lisp. Each change is of one of:
. Change SYMBOL to symbol or vice versa.
. Change package designator from string to symbol
. Change (intern "SOME-STRING" "SOME-PACKAGE") to
(intern (symbol-name '#:some-string) '#:some-package)
All trivial changes. Please apply.
Thanks,
Marco

[The changes were divided in 2 email because the patch is more that
40kb, but even that was not enough. It is actually devided in three
parts. They can be applied in any order.]
The attached patch changes the code to facilitate a possible future
implementation of modern mode Lisp. Each change is of one of:
. Change SYMBOL to symbol or vice versa.
. Change package designator from string to symbol
. Change (intern "SOME-STRING" "SOME-PACKAGE") to
(intern (symbol-name '#:some-string) '#:some-package)
All trivial changes. Please apply.
Thanks,
Marco

On Thu, Jun 28, 2007 at 01:51:32AM +0100, Marco Monteiro wrote:
> [The changes are divided in 2 email because the patch is more that 40kb.]
>
> The attached patch changes the code to facilitate a possible future
> implementation of modern mode Lisp. Each change is of one of:
>
> . Change SYMBOL to symbol or vice versa.
> . Change package designator from string to symbol
> . Change (intern "SOME-STRING" "SOME-PACKAGE") to
> (intern (symbol-name '#:some-string) '#:some-package)
>
> All trivial changes. Please apply.
I'm not very enthusiastic about this. Of course I see the value to
those users who need to run code portably both under SBCL and under
Allegro and who also choose to configure Allegro in its nonportable
modern mode. However, safe cheap trivial changes though they are, they
also seem to come with a global requirement that SBCL's code continue
to conform to the ANSI-Standard-as-revised-by-Allegro in order to
avoid code rot. Enforcing that seems to involve manual tedium or extra
automated checks at compile time.
We do already have checks like that for a narrower definition of
allowed whitespace than ANSI uses, for noncritical reasons like
improving CVS diff signal/noise ratio. So it's not completely
impractical or out of the question that a noncritical reason like
supporting more dialects of CL could justify this change. But it's not
clear to me that modern mode is something we should be working to
support. The patch doesn't seem completely out of the question, but my
snap reaction to this is more like "convince me" than "OK."
(Also, just as a personal favor, when someday you have been a
committer on a free software project for a while and someone mails in
a patch whose cover text terminates with "Please apply." I'd
appreciate it if you could please CC me with your reply.:-)
--
William Harold Newman <william.newman@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C
The law, in its august majesty, does not forbid the tired and poor
from inheriting citizenship.

william.newman@... (William Harold Newman) writes:
> However, safe cheap trivial changes though they are, they
> also seem to come with a global requirement that SBCL's code continue
> to conform to the ANSI-Standard-as-revised-by-Allegro in order to
> avoid code rot. Enforcing that seems to involve manual tedium or extra
> automated checks at compile time.
I'm inclined to agree that "modern"ising the code isn't a great
motivation for frobbing the codebase, but there is a possible other
motivation for at least some of the changes that Marco has sent in: at
the moment, SBCL fails to bootstrap if the builder has altered
(readtable-case *readtable*) in their image.
The cheap solution to this is doubtless to enforce :upcase in the
build scripts; on the other hand, there's a reasonable argument that
SBCL's code shouldn't depend on the case insensitivity (a subtly
different thing from depending on downcasedness of symbols, and simply
to minimize difficulty in reading code), so maybe we should enforce
:invert while building and fix the one or two places where this
matters?
This doesn't involve changing (intern "FOO" "BAR") to (intern '#:foo
'#:bar), where I have an irrational hatred for the second form; it
does involve changing various VOPs where currently we have
(inst foo)
LABEL
(inst bar)
(inst jmp label)
Just a (reasonably idle) thought.
Cheers,
Christophe

Christophe Rhodes wrote:
> I'm inclined to agree that "modern"ising the code isn't a great
> motivation for frobbing the codebase, but there is a possible other
> motivation for at least some of the changes that Marco has sent in: at
> the moment, SBCL fails to bootstrap if the builder has altered
> (readtable-case *readtable*) in their image.
>
> The cheap solution to this is doubtless to enforce :upcase in the
> build scripts; on the other hand, there's a reasonable argument that
> SBCL's code shouldn't depend on the case insensitivity (a subtly
> different thing from depending on downcasedness of symbols, and simply
> to minimize difficulty in reading code), so maybe we should enforce
> :invert while building and fix the one or two places where this
> matters?
This sounds like a good idea to me.
> This doesn't involve changing (intern "FOO" "BAR") to (intern '#:foo
> '#:bar), where I have an irrational hatred for the second form; it
Entirely rational to hate, I think -- esp. since the correct working
form is
(intern (string '#:foo) '#:bar)
yech -- ANSI in their infinite wisdom made the first argument of
INTERN a string, not a string designator.
I have yet to see any convincing arguments in favor of supporting
a "modern" mode, and I don't quite see benefits of maintaining
one patch in the SBCL tree in order to allow an external "modern"
mode implementation to work.
If someone has large codebase written for m-mode Allegro that
they want to port to SBCL, then yes, maybe a m-mode SBCL might be
a good way to do this, but I suspect that there would be more benefit
to be had from an automatic tool that helps convert such codebases
to standard CL.
Cheers,
-- Nikodemus

William Harold Newman wrote:
> On Thu, Jun 28, 2007 at 01:51:32AM +0100, Marco Monteiro wrote:
>> [The changes are divided in 2 email because the patch is more that
40kb.]
>>
>> The attached patch changes the code to facilitate a possible future
>> implementation of modern mode Lisp. Each change is of one of:
>
> I'm not very enthusiastic about this. Of course I see the value to
> those users who need to run code portably both under SBCL and under
> Allegro and who also choose to configure Allegro in its nonportable
> modern mode. However, safe cheap trivial changes though they are, they
> also seem to come with a global requirement that SBCL's code continue
> to conform to the ANSI-Standard-as-revised-by-Allegro in order to
> avoid code rot. Enforcing that seems to involve manual tedium or extra
> automated checks at compile time.
>
> We do already have checks like that for a narrower definition of
> allowed whitespace than ANSI uses, for noncritical reasons like
> improving CVS diff signal/noise ratio. So it's not completely
> impractical or out of the question that a noncritical reason like
> supporting more dialects of CL could justify this change. But it's not
> clear to me that modern mode is something we should be working to
> support. The patch doesn't seem completely out of the question, but my
> snap reaction to this is more like "convince me" than "OK."
To make SBCL code base support modern mode in a non-hackish way would be
a big undertaking and not worth the work. I'm not advocating it. SBCL is
and should continue to be a good CL compiler. Besides, almost no one
wants or needs modern mode in SBCL.
The code in Brian Downing's response to your email almost works. To
really make it work, you need my patch and some additional, small but
more intrusive changes, like declaring that some functions cannot be
inlined, etc. Some 300 additional lines of code and you can have modern
mode.
But this is an hack, and should not be included in the code base. The
changes in my patch allow such an hack to work and to be maintained
outside the SBCL source tree. The changes are trivial enough that they
should not cause any trouble to anyone. And the maintenance of the hack
outside the source tree would be much easier, which is always good (for
me, at least).
Please, apply. :)
Marco

William Harold Newman wrote:
> On Thu, Jun 28, 2007 at 07:11:15AM +0100, Christophe Rhodes wrote:
>> william.newman@... (William Harold Newman) writes:
>>
>>> However, safe cheap trivial changes though they are, they
>>> also seem to come with a global requirement that SBCL's code continue
>>> to conform to the ANSI-Standard-as-revised-by-Allegro in order to
>>> avoid code rot. Enforcing that seems to involve manual tedium or extra
>>> automated checks at compile time.
>> I'm inclined to agree that "modern"ising the code isn't a great
>> motivation for frobbing the codebase, but there is a possible other
>> motivation for at least some of the changes that Marco has sent in: at
>> the moment, SBCL fails to bootstrap if the builder has altered
>> (readtable-case *readtable*) in their image.
>
> True, but is there something special about tweaking READTABLE-CASE
> compared to setting *READ-BASE* to 16? It's not just a rhetorical
> question --- for all I know, there is some formal fundamental divide
> where READTABLE-CASE is on one side and *READ-BASE* is on the other.
> But my informal impression was that software can reasonably expect
> both of them to be in the default setting.
Is it reasonable to have SBCL check that these expectations are indeed
correct before building, so that the form of the failure is not a
catastrophic and indecipherable error but a specific message about the
non-default setting which is at fault? And why not just fix the setting
to our expected value instead of making the code resistant to :invert
readtable-case? The duration of the image used in bootstrapping is
limited, so presumably (|CL|:|SETF| (|CL|:|READTABLE-CASE|
|CL|:|*READTABLE*|) :|UPCASE|) is not problematic.
--
Brian Mastenbrook
brian@...
http://brian.mastenbrook.net/

On Sun, Jul 01, 2007 at 06:57:20PM -0500, Brian Mastenbrook wrote:
> William Harold Newman wrote:
> > True, but is there something special about tweaking READTABLE-CASE
> > compared to setting *READ-BASE* to 16? It's not just a rhetorical
> > question --- for all I know, there is some formal fundamental divide
> > where READTABLE-CASE is on one side and *READ-BASE* is on the other.
> > But my informal impression was that software can reasonably expect
> > both of them to be in the default setting.
>
> Is it reasonable to have SBCL check that these expectations are indeed
> correct before building, so that the form of the failure is not a
> catastrophic and indecipherable error but a specific message about the
> non-default setting which is at fault? And why not just fix the setting
> to our expected value instead of making the code resistant to :invert
> readtable-case? The duration of the image used in bootstrapping is
> limited, so presumably (|CL|:|SETF| (|CL|:|READTABLE-CASE|
> |CL|:|*READTABLE*|) :|UPCASE|) is not problematic.
I think that'd be a perfectly reasonable little bit of caution, yes.
--
William Harold Newman <william.newman@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C
Ubi saeva indignatio ulterius cor lacerare nequit. -- Jonathan Swift's epitaph

On Tue, Jul 03, 2007 at 08:30:57AM -0500, William Harold Newman wrote:
> Instead of trying to tidy up whatever mutant *READTABLE* you find slot
> by slot, it might make sense to use
> (setf *readtable* (copy-readtable nil))
> to just start over from scratch.
This also sounded good, until I tried it and remembered that LOAD binds
*READTABLE*, so that:
(|CL|:|SETF| |CL|:|*READTABLE*| (|CL|:|COPY-READTABLE| |CL|:|NIL|))
(cl:load "tools-for-build/sane-...")
would have to be done in make-host-1.lisp, make-host-2.lisp, and
make-genesis-2.lisp, which is significantly uglier.
(ObAnsiQuestion: Why the heck is the readtable case a property of
*READTABLE*, but *READ-BASE* and the other *READ-** are their own
specials?)
Perhaps a better solution would be to change make-host-1.sh (and the
others) to do:
$SBCL_XC_HOST <<EOF || exit 1
(|CL|:|WITH-STANDARD-IO-SYNTAX| (|CL|:|LOAD| "make-host-1.lisp"))
EOF
Except you'd have to bind *PRINT-READABLY* to NIL somewhere in there
too...
Probably trying to solve this problem in general is more trouble than
it's worth.
-bcd

On Thu, Jun 28, 2007 at 07:11:15AM +0100, Christophe Rhodes wrote:
> william.newman@... (William Harold Newman) writes:
>
> > However, safe cheap trivial changes though they are, they
> > also seem to come with a global requirement that SBCL's code continue
> > to conform to the ANSI-Standard-as-revised-by-Allegro in order to
> > avoid code rot. Enforcing that seems to involve manual tedium or extra
> > automated checks at compile time.
>
> I'm inclined to agree that "modern"ising the code isn't a great
> motivation for frobbing the codebase, but there is a possible other
> motivation for at least some of the changes that Marco has sent in: at
> the moment, SBCL fails to bootstrap if the builder has altered
> (readtable-case *readtable*) in their image.
True, but is there something special about tweaking READTABLE-CASE
compared to setting *READ-BASE* to 16? It's not just a rhetorical
question --- for all I know, there is some formal fundamental divide
where READTABLE-CASE is on one side and *READ-BASE* is on the other.
But my informal impression was that software can reasonably expect
both of them to be in the default setting.
> This doesn't involve changing (intern "FOO" "BAR") to (intern '#:foo
> '#:bar), where I have an irrational hatred for the second form; it
> does involve changing various VOPs where currently we have
>
> (inst foo)
> LABEL
> (inst bar)
> (inst jmp label)
In this case, writing this as
> (inst foo)
> label
> (inst bar)
> (inst jmp label)
seems more natural to me; the old way isn't unnatural enough that I
was motivated to change it, but I'd consider the all-one-case form to
be a (very tiny) improvement.
--
William Harold Newman <william.newman@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C
"If you could have one wish, what would it be?"
"I wish that all Web browsers would drop their proprietary tags and conform to
the W3C's HTML 4.01 and the ECMA Script 262 v.2 specifications."
-- <http://hackles.org/cgi-bin/archives.pl?request=17&gt;

william.newman@... (William Harold Newman) writes:
> True, but is there something special about tweaking READTABLE-CASE
> compared to setting *READ-BASE* to 16? It's not just a rhetorical
> question --- for all I know, there is some formal fundamental divide
> where READTABLE-CASE is on one side and *READ-BASE* is on the other.
> But my informal impression was that software can reasonably expect
> both of them to be in the default setting.
It's not a fundamental divide, but an empirical observation: people
tend to set READTABLE-CASE in their initfiles and/or dump (personal)
cores with an unusual value, leading to reports of failures to build
sbcl and a certain amount of tedious remote debugging -- whereas I've
never yet encountered a case where a prospective user has failed to
build sbcl because they were using an environment with a non-standard
value of *READ-BASE*.
Cheers,
Christophe