From: Marco M. <ma...@ac...> - 2007-06-28 00:51:41
Attachments:
patch2.diff.gz
|
[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 |
From: Marco M. <ma...@ac...> - 2007-06-28 01:21:01
Attachments:
patch.diff.gz
|
[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 |
From: Marco M. <ma...@ac...> - 2007-06-28 01:21:03
Attachments:
patch3.diff.gz
|
[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 |
From: <wil...@ai...> - 2007-06-28 01:34:41
|
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 <wil...@ai...> 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. |
From: <bdo...@la...> - 2007-06-28 04:23:45
|
On Wed, Jun 27, 2007 at 08:39:19PM -0500, William Harold Newman wrote: > On Thu, Jun 28, 2007 at 01:51:32AM +0100, Marco Monteiro wrote: > > The attached patch changes the code to facilitate a possible future > > implementation of modern mode Lisp. > > 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. Besides, strictly speaking you can get something very close to "modern"-mode SBCL without changing any code at all. After running this I can (defun square (x) (* x x)) and (square 4) => 16, so it must work perfectly! A saved core loads too. (Disclaimer: I wrote this for giggles, I never plan on using it. If it breaks you are legally entitled to keep both pieces. I may go to hell for even posting this. Do not taunt Happy Fun Ball.) ------------------------------------------------------------------------ (eval-when (:compile-toplevel :load-toplevel :execute) (defun get-primitive-object-offset (obj-name slot-name) (let ((obj (find obj-name sb-vm:*primitive-objects* :key #'sb-vm:primitive-object-name))) (let ((lowtag (eval (sb-vm:primitive-object-lowtag obj)))) (when lowtag (let ((slot (find slot-name (sb-vm:primitive-object-slots obj) :key #'sb-vm:slot-name))) (- (* (sb-vm:slot-offset slot) sb-vm:n-word-bytes) lowtag))))))) (defconstant +symbol-name-offset+ (get-primitive-object-offset 'symbol 'sb-vm::name)) (defun %set-symbol-name (sym name) (setf (sb-sys:sap-ref-word (sb-sys:int-sap (sb-kernel:get-lisp-obj-address sym)) +symbol-name-offset+) (sb-kernel:get-lisp-obj-address name))) (defun make-lisp-modern () (let ((symbols (make-hash-table)) (packages (list-all-packages))) (do-all-symbols (s) (setf (gethash s symbols) t)) ;; Hack up our symbols! (maphash (lambda (s ignore) (declare (ignore ignore)) (when (string= (symbol-name s) (string-upcase (symbol-name s))) (%set-symbol-name s (string-downcase (symbol-name s))))) symbols) ;; Oh nuts, rehash our packages, quick! (dolist (package packages) (dolist (table (list (sb-kernel:package-internal-symbols package) (sb-kernel:package-external-symbols package))) (sb-impl::resize-package-hashtable table (sb-impl::package-hashtable-size table)))) ;; Phew. (setf (readtable-case *readtable*) :preserve)) ;; We sure as hell can't claim this anymore. (setf *features* (remove :ansi-cl *features*)) (setf *features* (remove :common-lisp *features*))) ;;; (make-lisp-modern) ;;; (save-lisp-and-die "modern.core") ------------------------------------------------------------------------ -bcd |
From: Christophe R. <cs...@ca...> - 2007-06-28 06:18:17
|
wil...@ai... (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 |
From: Nikodemus S. <nik...@ra...> - 2007-06-28 11:09:06
|
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 |
From: Marco M. <ma...@ac...> - 2007-06-28 10:44:25
|
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 |
From: Brian M. <br...@ma...> - 2007-07-01 23:57:33
|
William Harold Newman wrote: > On Thu, Jun 28, 2007 at 07:11:15AM +0100, Christophe Rhodes wrote: >> wil...@ai... (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 br...@ma... http://brian.mastenbrook.net/ |
From: <wil...@ai...> - 2007-07-02 17:58:14
|
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 <wil...@ai...> 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 |
From: <bdo...@la...> - 2007-07-02 22:25:56
|
Add tools-for-build/sane-build-environment.lisp, which carefully sets some important reader and printer settings back to the way the standard specifies (and SBCL requires to be successfully built). This should guard against common build failures caused by customizations to end-users' Lisp init files. (slam.sh is not affected, as anybody running it should have a sane build environment to begin with.) --- With this patch I can build with: :; cat ~/.sbclrc (setf *print-base* 36) (setf *print-case* :downcase) (setf (readtable-case *readtable*) :preserve) (SETF *READ-BASE* 36) :; sh make.sh sbcl Some questions: * Should (setf *print-level* 5 *print-length* 5) be rolled into sane-build-environment.lisp? That is currently executed everywhere s-b-e.lisp is now, but it's not strictly restoring standard behavior. * Should *READ-DEFAULT-FLOAT-FORMAT* be explicitly set to SINGLE-FLOAT? * Does anything else need to be cleaned up? I'll commit this if it looks okay to everyone. make-genesis-2.lisp | 2 ++ make-host-1.lisp | 2 ++ make-host-2.lisp | 2 ++ tools-for-build/sane-build-environment.lisp | 12 ++++++++++++ 4 files changed, 18 insertions(+), 0 deletions(-) create mode 100644 tools-for-build/sane-build-environment.lisp diff --git a/make-genesis-2.lisp b/make-genesis-2.lisp index 9bc9e21..bc1c7aa 100644 --- a/make-genesis-2.lisp +++ b/make-genesis-2.lisp @@ -1,3 +1,5 @@ +(|CL|:|LOAD| "tools-for-build/sane-build-environment.lisp") + (setf *print-level* 5 *print-length* 5) (load "src/cold/shared.lisp") (in-package "SB-COLD") diff --git a/make-host-1.lisp b/make-host-1.lisp index 0a22dfe..380bbcf 100644 --- a/make-host-1.lisp +++ b/make-host-1.lisp @@ -1,3 +1,5 @@ +(|CL|:|LOAD| "tools-for-build/sane-build-environment.lisp") + ;;; (We want to have some limit on print length and print level during ;;; bootstrapping because PRINT-OBJECT only gets set up rather late, ;;; and running without PRINT-OBJECT it's easy to fall into printing diff --git a/make-host-2.lisp b/make-host-2.lisp index 8bc96bf..34b9cd0 100644 --- a/make-host-2.lisp +++ b/make-host-2.lisp @@ -1,3 +1,5 @@ +(|CL|:|LOAD| "tools-for-build/sane-build-environment.lisp") + ;;; Set up the cross-compiler. (setf *print-level* 5 *print-length* 5) (load "src/cold/shared.lisp") diff --git a/tools-for-build/sane-build-environment.lisp b/tools-for-build/sane-build-environment.lisp new file mode 100644 index 0000000..7a60e2d --- /dev/null +++ b/tools-for-build/sane-build-environment.lisp @@ -0,0 +1,12 @@ +;;;; Ensure our host Lisp build environment is sane enough to build SBCL. +;;;; We don't run this in the target SBCL, as we can safely assume +;;;; it is sane, as we just built it and it runs with init files +;;;; disabled. + +(|CL|:|SETF| (|CL|:|READTABLE-CASE| |CL|:|*READTABLE*|) :|UPCASE|) +(cl:setf cl:*read-base* #10r10) + +(cl:in-package "CL-USER") + +(setf *print-case* :upcase + *print-base* 10) -- 1.5.2.2 |
From: <wil...@ai...> - 2007-07-03 13:26:05
|
On Mon, Jul 02, 2007 at 05:25:40PM -0500, Brian Downing wrote: > Add tools-for-build/sane-build-environment.lisp, which carefully sets > some important reader and printer settings back to the way the standard > specifies (and SBCL requires to be successfully built). This should > guard against common build failures caused by customizations to > end-users' Lisp init files. > > (slam.sh is not affected, as anybody running it should have a sane build > environment to begin with.) > --- > With this patch I can build with: > :; cat ~/.sbclrc > (setf *print-base* 36) > (setf *print-case* :downcase) > (setf (readtable-case *readtable*) :preserve) > (SETF *READ-BASE* 36) > :; sh make.sh sbcl > > Some questions: > * Should (setf *print-level* 5 *print-length* 5) be rolled into > sane-build-environment.lisp? That is currently executed > everywhere s-b-e.lisp is now, but it's not strictly restoring > standard behavior. I think that would make sense. I might write it something like ;; default settings that the build expects (setf *print-base* 10. (readtable-case *readtable*) :preserve ...) ;; non-default settings that the build expects (setf *print-length* 5 ; since we don't need or want enormous... *print-level* 5 ; ...(or infinite) PRINTed expressions ...) and ensure that whatever text you use to document it doesn't suggest too strongly that you're only restoring defaults. > * Does anything else need to be cleaned up? 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. -- William Harold Newman <wil...@ai...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C Unable or unwilling to attack me personally, he is reduced to countering my arguments. -- http://highclearing.com/index.php/archives/2006/06/15/5210 |
From: <bdo...@la...> - 2007-07-04 08:15:26
|
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 |
From: <bdo...@la...> - 2007-07-04 09:00:37
|
Add tools-for-build/load-with-xc-host, which loads a file into the SBCL_XC_HOST Lisp, carefully setting reader and printer settings from a WITH-STANDARD-IO-SYNTAX baseline. This should guard against common build failures caused by customizations to end-users' Lisp init files. (slam.sh is not affected, as anybody running it should have a sane build environment to begin with.) --- I think this is a much better solution than my previous effort. It should reset all reader and printer settings to a known baseline, and isolates all the escaping ugliness into one place. make-genesis-2.sh | 2 +- make-host-1.sh | 2 +- make-host-2.sh | 2 +- tools-for-build/load-with-xc-host | 11 +++++++++++ 4 files changed, 14 insertions(+), 3 deletions(-) create mode 100755 tools-for-build/load-with-xc-host diff --git a/make-genesis-2.sh b/make-genesis-2.sh index 4b9973e..ca70ef7 100644 --- a/make-genesis-2.sh +++ b/make-genesis-2.sh @@ -30,7 +30,7 @@ echo //entering make-genesis-2.sh # file at that time; but we needed to run it earlier in order to # get to where we can write a .core file.) echo //loading and running GENESIS to create cold-sbcl.core -$SBCL_XC_HOST < make-genesis-2.lisp +tools-for-build/load-with-xc-host make-genesis-2.lisp echo //testing for consistency of first and second GENESIS passes if diff -r src/runtime/genesis output/genesis-2; then diff --git a/make-host-1.sh b/make-host-1.sh index 3bd8d74..58615ef 100644 --- a/make-host-1.sh +++ b/make-host-1.sh @@ -28,4 +28,4 @@ export LANG LC_ALL # header file sbcl.h which will be needed to create the C runtime # environment. echo //building cross-compiler, and doing first genesis -$SBCL_XC_HOST < make-host-1.lisp || exit 1 +tools-for-build/load-with-xc-host make-host-1.lisp || exit 1 diff --git a/make-host-2.sh b/make-host-2.sh index 347400e..c46ac33 100644 --- a/make-host-2.sh +++ b/make-host-2.sh @@ -45,7 +45,7 @@ rm -f output/after-xc.core # the fasl files into the new host Lisp, and that doesn't seem to be # an enormously important disadvantage, either.) echo //running cross-compiler to create target object files -$SBCL_XC_HOST < make-host-2.lisp +tools-for-build/load-with-xc-host make-host-2.lisp # Run GENESIS (again) in order to create cold-sbcl.core. (The first # time was before we ran the cross-compiler, in order to create the diff --git a/tools-for-build/load-with-xc-host b/tools-for-build/load-with-xc-host new file mode 100755 index 0000000..88b1e44 --- /dev/null +++ b/tools-for-build/load-with-xc-host @@ -0,0 +1,11 @@ +#!/bin/sh + +# Building SBCL requires reasonably standard reader settings. +# Carefully load a Lisp file into our XC host Lisp, restoring standard +# behavior wherever possible to guard against user configuration of +# reader and printer control variables. +$SBCL_XC_HOST <<EOF +(|CL|:|WITH-STANDARD-IO-SYNTAX| + (|CL|:|SETF| |CL|:|*PRINT-READABLY*| |CL|:|NIL|) + (|CL|:|LOAD| "$1")) +EOF -- 1.5.2.GIT |
From: <wil...@ai...> - 2007-07-01 18:19:45
|
On Thu, Jun 28, 2007 at 07:11:15AM +0100, Christophe Rhodes wrote: > wil...@ai... (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 <wil...@ai...> 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> |
From: Christophe R. <cs...@ca...> - 2007-07-01 18:34:58
|
wil...@ai... (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 |