interactive top level keeps waiting for input after #e1@1.0

[symingz]

In Chez Scheme version 9.5.8, at the interactive top level, after typing #e1@1.0 and enter, the program keeps waiting for further input. The same happens for #e1@1, but not #i1@1.0 or #i1@1. My guess is that this is because 1@1 can not be represented exactly in Chez Scheme, which is understandable, but it may be better to return an error instead of keep waiting for inputs.

[akeep]

I think the issue is that 1@1 is inherently an inexact number, so #e which indicates we have an exact number followed by 1@1, which is inexact is sort of nonsensical. It is possible to generate an exact representation that is roughly the same by either using (exact 1@1) or #e1216652631687587/2251799813685248+3789648413623927/4503599627370496i, which is the roughly exact equivalent.

[symingz]

I agree that #e1@1.0 is nonsensical, but for the REPL, instead of waiting for further input after seeing #e1@1.0, I think raising an error makes more sense.

[akeep]

The issue here is the expression editor, where return doesn't really mean evaluate the current expression, it means: if the current expression is complete, evaluate it, otherwise wait for more input (and possibly add a newline and indent appropriate the expression).

It determines this by calling read-token and if read-token raises an error, it assumes it needs to wait for more input. Unfortunately, it cannot differentiate between the kind of error raised when the token is truly incomplete: (say like the start of a character token: #\) and when it is an error (as in the #e1@1 case).

The expression editor also provides CTRL-j, which indicates the current expression should be evaluated:

If we type in #e1@1 at the repl:

% scheme
Chez Scheme Version 9.5.5
Copyright 1984-2020 Cisco Systems, Inc.

> #e1@1

and hit CTRL-j we get the error displayed in a banner above the repl:

% scheme
Chez Scheme Version 9.5.5
Copyright 1984-2020 Cisco Systems, Inc.

-----------------------------------------------------
read: cannot represent #e1@1
-----------------------------------------------------
> #e1@1

You will also see this by disabling the expression editor:

% scheme --eedisable
Chez Scheme Version 9.5.5
Copyright 1984-2020 Cisco Systems, Inc.

> #e1@1

Exception in read: cannot represent #e1@1
Type (debug) to enter the debugger.

Where there is no filter and return and CTRL-j both simply evaluate whatever is in the buffer.

Unfortunately, read-token reports all of these exceptions as i/o-port-error so the expression editor does not have a good way of differentiating these two scenarios, outside of very hacky inspection of the error message. It is possible read-token could be taught to handle these errors differently, but it would require rearchitecting how read-token raises exceptions and then teaching the expression editor to respond differently to these different situations.

[symingz]

I see. Thanks for the detailed explanation!