Title Lisp reader doesn't handle `?(' correctly
Type feature Module core code 21.4, core code 21.5
Severity inconvenience Platform N/A
Keywords Nosy List aidan, stephen
These controls should only be changed by committers and tracker administrators.
Status assigned   Reason
Priority normal   Assigned To

Created on 2009-08-06.15:28:38 by stephen, last changed 2009-08-10.05:43:35 by stephen.

msg1814 [hidden] ([hidden]) Date: 2009-08-10.05:43:35
  Message-ID: <>
Of course `( 40)' is a perfectly valid s-expression.  But `?( 40)' is 
not, and eval-print-last-sexp should keep scanning backward to 
disambiguate, just as it must to disambiguate the case `\( 40)'.

I don't understand the argument about "looking too much at preceding 
buffer contents".  Several sorts of syntax require similar "lookbehind":  
apostrophe and backtick, reverse solidus, symbols.  But we handle those.
msg1813 [hidden] ([hidden]) Date: 2009-08-09.18:34:18
  Message-ID: <>
( 40) is a perfectly valid s-expression, and there's a good argument
that it should be read as such. Having #'eval-print-last-sexp look too
much at the buffer's contents before the sexp is behaviour no-one wants,
there's too much crap legitimately in that buffer.  

I agree that the behaviour is inconsistent, though. char_quoted in
syntax.c could be modified to do what you seem to want, but I don't know
enough about that file right now to say that it'll have the limited
interactions we would like.
msg1811 [hidden] ([hidden]) Date: 2009-08-09.17:02:50
  Message-ID: <>
I disagree that that is correct.  `?(' is a perfectly valid s-expression 
and should be read as such.  You don't explain, but I presume you mean 
that `?(' is evaluated by scanning backward until the open parenthesis, 
at which time an unbalanced parenthesis error is detected and signaled.  
However, by that logic, `?\(' should be evaluated in the same way.  It 
is not; it evaluates to the character OPEN PARENTHESIS as you would 
expect.  The relevant documentation is (lispref)The Character Type, and 
it explicitly says that `?(' is completely equivalent to `?\(' except 
that `?(' should be avoided because it can confuse tools other than the 
Lisp reader that parse Lisp.

So it's documented where it should be: in the bug tracker. ;-)
msg1810 [hidden] ([hidden]) Date: 2009-08-09.12:00:52
  Message-ID: <>
In *scratch*, you're calling #'eval-print-last-sexp on the sexp before
point, and it's doing the correct thing in throwing an error in this case. 

If you call explicitly (eval (read "(eq ?( 40)")) no error is thrown,
and you get nil. If you call explicitly (eval (read "(eq ?( ?\\x28)")),
no error is thrown and the result is t.

Where do we document this? We should add a note there to mention that it
doesn't work in *scratch*.
msg1803 [hidden] ([hidden]) Date: 2009-08-06.15:28:38
  Message-ID: <>
In *scratch*, the form

    (eq ?( 40)

throws an error.  Although it is highly recommended to use the syntax `?\(', the reader 
is documented to accept `?('.

Tests of the form above should be added to tests/automated.

I do not yet know if a similar problem occurs in 21.4.

Aidan, you're the most recent person to work on the Lisp reader, so you probably 
understand it better than anyone else.  But if you haven't got time to work on it, 
please assign it back to me.
Date User Action Args
2009-08-10 05:43:35stephensetmessages: + msg1814
2009-08-09 18:34:18aidansetmessages: + msg1813
2009-08-09 17:02:50stephensetmessages: + msg1811
2009-08-09 12:00:52aidansettype: defect -> feature
messages: + msg1810
2009-08-06 15:28:38stephencreate