From: Tobias C. R. <tc...@fr...> - 2008-09-13 11:25:14
|
WITH-STANDARD-IO-SYNTAX binds *READTABLE* to SB-IMPL::*STANDARD-READTABLE*, which may then possibly get modified. Even though it is verboten by the spec to modify the standard-readtable, I think it'd best if SBCL tried to save a user from shooting in his foot by signalling an error in such a case. As I'm looking at the readtable related code for other reasons anyway, I'd like to implement such explicit checking. a) Should SET-MACRO-CHARACTER etc. check for its argument being EQ to *STANDARD-READTABLE*? b) Should I introduce a new slot READONLYP which can be set by the user as an extension, and which is set for *STANDARD-READTABLE* by default, and which results in an error when such a readtable is tried to be modified? -T. |
From: Tobias C. R. <tc...@fr...> - 2008-09-14 13:45:00
|
"Tobias C. Rittweiler" <tc...@fr...> writes: > WITH-STANDARD-IO-SYNTAX binds *READTABLE* to SB-IMPL::*STANDARD-READTABLE*, > which may then possibly get modified. > > Even though it is verboten by the spec to modify the standard-readtable, > I think it'd best if SBCL tried to save a user from shooting in his foot > by signalling an error in such a case. Instead of signalling an error, signalling a warning may be considered to be a better choice. What do you think? -T. |
From: Christophe R. <cs...@ca...> - 2008-09-14 14:24:19
|
"Tobias C. Rittweiler" <tc...@fr...> writes: > "Tobias C. Rittweiler" <tc...@fr...> writes: > >> WITH-STANDARD-IO-SYNTAX binds *READTABLE* to SB-IMPL::*STANDARD-READTABLE*, >> which may then possibly get modified. >> >> Even though it is verboten by the spec to modify the standard-readtable, >> I think it'd best if SBCL tried to save a user from shooting in his foot >> by signalling an error in such a case. > > Instead of signalling an error, signalling a warning may be considered > to be a better choice. What do you think? I'd signal an error, with reference-condition mixin pointing to the place in the standard which specifies that modifying the standard readtable is an error. Cheers, Christophe |
From: Julian S. <der...@we...> - 2008-09-15 00:33:56
|
"Tobias C. Rittweiler" <tc...@fr...> writes: > WITH-STANDARD-IO-SYNTAX binds *READTABLE* to SB-IMPL::*STANDARD-READTABLE*, > which may then possibly get modified. You could bind it to a copy of SB-IMPL::*STANDARD-READTABLE*. Then you wouldn't have to change any code (except the trivial change to WITH-STANDARD-IO-SYNTAX) and still keep the user from shooting in his foot. Regards, -- Julian Stecklina Well, take it from an old hand: the only reason it would be easier to program in C is that you can't easily express complex problems in C, so you don't. - Erik Naggum (in comp.lang.lisp) |
From: Tobias C. R. <tc...@fr...> - 2008-09-15 09:50:50
|
Julian Stecklina <der...@we...> writes: > "Tobias C. Rittweiler" <tc...@fr...> writes: > > > WITH-STANDARD-IO-SYNTAX binds *READTABLE* to SB-IMPL::*STANDARD-READTABLE*, > > which may then possibly get modified. > > You could bind it to a copy of SB-IMPL::*STANDARD-READTABLE*. Then you > wouldn't have to change any code (except the trivial change to > WITH-STANDARD-IO-SYNTAX) and still keep the user from shooting in his > foot. There's an explicit comment about this being perhaps too costly. Also, you could still modify the standard-readtable by passing NIL as designator to the reader-macro related functions. We could also make them copy the standard-readtable (this is explicitly allowed by the specification), but I think the signalling would be good for some library I'm writing, and which is the true reason behind my endeavor. :-) -T. |
From: Tobias C. R. <tc...@fr...> - 2008-09-15 14:48:02
Attachments:
reader-cosmetic-fixes.diff
|
"Tobias C. Rittweiler" <tc...@fr...> writes: > Even though it is verboten by the spec to modify the standard-readtable, > I think it'd best if SBCL tried to save a user from shooting in his foot > by signalling an error in such a case. > > As I'm looking at the readtable related code for other reasons anyway, > I'd like to implement such explicit checking. The attached patch fixes some cosmetic stuff only. FIXME comments in reader.lisp talked about changing macros to inline functions. I did this. -T. |
From: Tobias C. R. <tc...@fr...> - 2008-09-15 15:10:57
Attachments:
reader-check-read-buffer.diff
|
Currently, calling a READ function at the toplevel with RECURSIVE-P being true results in an internal-implementation-leaking error. The attached patch adds the necessary code to catch this case and signal an error with a more appropriate message The specification doesn't seem to prescribe any behaviour explicitly. Other implementations tend to just accept this case, and work. (I haven't stress-tested them for any quirky behaviour resulting from this case, though.) -T. |
From: Tobias C. R. <tc...@fr...> - 2008-09-16 04:55:47
Attachments:
readtable-fndb-entries.diff
|
The following patch corrects the DEFKNOWNs for SET-MACRO-CHARACTER, and SET-DISPATCH-MACRO-CHARACTER. -T. |
From: Tobias C. R. <tc...@fr...> - 2008-09-16 05:00:10
Attachments:
check-for-standard-readtable.diff
|
The following patch adds the checking for modification of the standard-readtable. -T. |
From: Tobias C. R. <tc...@fr...> - 2008-09-16 05:05:13
Attachments:
check-for-standard-readtable-pt2.diff
|
The following patch adds the misc. stuff needed for the previous patch to work. -T. |
From: Tobias C. R. <tc...@fr...> - 2008-09-16 10:39:05
|
[... lots of patches ...] Richard Kreuter suggested a nicer way of dealing with some bootstrapping issue. If I set up everything right, all the changes can now be pulled from the branch tcr-reader-hacking in the Git repository available at http://repo.or.cz/w/sbcl/tcr.git -T. |