Numeric Input Error on EOF or Invalid Number – Bug or Implementation Detail?

[sy-python]

Description:
This interpreter, when parsing numeric input, raises an error (ShakespeareRuntimeError) when encountering an invalid number or reaching the end of file (EOF). However, other implementations of the Shakespeare Programming Language (SPL) tend to return 0 in these cases instead of raising an error.

If this is a deliberate implementation choice, please indicate as such in project files. If not, then it is a bug and should be fixed.

[zmbc]

I think I slightly prefer the error behavior from a design standpoint, but would prefer to be consistent with other implementations and especially the language spec. Is this behavior in the spec, and which implementations do this?

[sy-python]

It's not in the language specification, but also neither is the fact that -1 is returned by the character read input at EoF. The canonical C implementation does it, but it also consumes the whole line from input when requesting a number, so caveat emptor.
Considering the language doesn't have builtin error handling, I personally prefer the non-error approach and in my (very opinionated) fork I have done exactly so.

[zmbc]

It's not in the language specification, but also neither is the fact that -1 is returned by the character read input at EoF. The canonical C implementation does it, but it also consumes the whole line from input when requesting a number, so caveat emptor.

Ah yes, this is ringing a bell. There are a lot of holes in both the spec and the reference implementation in this area. See #5

I think I agree with you that raising a Python error here doesn't make sense. It's unfortunate that there is no "flag" value you could return that is unambiguous -- i.e. if 0 means "bad input" then you can't tell when the user actually entered 0.

Would you be open to adding a note about this to the documentation somewhere, as part of #25?

[sy-python]

if 0 means "bad input" then you can't tell when the user actually entered 0.

That is why in my main fork, I made it so numeric input doesn't consume newline. That means that you are forced to take a character input between any two numeric inputs, and can check that for eof

[zmbc]

But not invalid number, right? So a program that does one numeric input, one character input, and then one numeric input cannot tell the difference between "0 1" and "a 1". I think this is a fundamental problem with any return value from numeric input being a possible non-error.

[sy-python]

If you run numeric, character, numeric on "a 1", you get 0 and 97, and there is still " 1" left. Basically, if there is no valid number, nothing is consumed. It does require storing the last byte of input in memory

[zmbc]

Ah okay -- in that case that wasn't the best example. Here's a better one: there is no difference between "0a1" and "a1". The point being, there is a loss of information here, because the error flag is also a valid return value. No way around that, right?

…

On Sun, Dec 8, 2024, 5:54 PM Sy ***@***.***> wrote: If you run numeric, character, numeric on "a 1", you get 0 and 97, and there is still " 1" left. Basically, if there is no valid number, nothing is consumed. It does require storing the last byte of input in memory — Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADF5EUAE5EBW3YSW5MKYGZL2ETZ5TAVCNFSM6AAAAABSZKY5KOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRWGYZDAMRSGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[sy-python]

I don't think there is a way around that. The problem is that the alternative makes numeric input potentially dangerous. Consider working with input like "1\n23\n45\n". If reading a number after eof throws, the only way to work with this input is by avoiding numeric input and parsing this by-character, which defeats the purpose of having two separate input commands.

[zmbc]

That makes sense. I think I'm convinced it is better to return a flag value in these cases. I'm not sure I like 0 being used for both. Is there any other reason you like 0, besides that it's what the reference implementation does? Since the behavior is already so different, I think I'd go for something like -1 on EOF, -2 on invalid number.

…

On Sun, Dec 8, 2024, 8:33 PM Sy ***@***.***> wrote: I don't think there is a way around that. The problem is that the alternative makes numeric input potentially dangerous. Consider working with input like "1\n23\n45\n". If reading a number after eof throws, the only way to work with this input is by avoiding numeric input and parsing this by-character, which defeats the purpose of having two separate input commands. — Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADF5EUFNMB4Z2VR6UXLGPST2EUMTLAVCNFSM6AAAAABSZKY5KOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRWHA3DSNBUGU> . You are receiving this because you commented.Message ID: ***@***.***>

[sy-python]

There isn't really any difference per se, because -1 and -2 are valid non-error inputs (well, not in this version, see #22). I can implement either. On Mon, Dec 9, 2024 at 7:41 PM Zeb Burke-Conte ***@***.***> wrote:

…

That makes sense. I think I'm convinced it is better to return a flag value in these cases. I'm not sure I like 0 being used for both. Is there any other reason you like 0, besides that it's what the reference implementation does? Since the behavior is already so different, I think I'd go for something like -1 on EOF, -2 on invalid number. On Sun, Dec 8, 2024, 8:33 PM Sy ***@***.***> wrote: > I don't think there is a way around that. The problem is that the > alternative makes numeric input potentially dangerous. Consider working > with input like "1\n23\n45\n". If reading a number after eof throws, the > only way to work with this input is by avoiding numeric input and parsing > this by-character, which defeats the purpose of having two separate input > commands. > > — > Reply to this email directly, view it on GitHub > < #23 (comment)>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/ADF5EUFNMB4Z2VR6UXLGPST2EUMTLAVCNFSM6AAAAABSZKY5KOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRWHA3DSNBUGU> > . > You are receiving this because you commented.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJU2B76XUN2CO4XZUEHYVCD2EXB4JAVCNFSM6AAAAABSZKY5KOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRYGY2DSMJTGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[zmbc]

Yes, they are valid, so it doesn't avoid the issue -- I'd just prefer to (a) differentiate invalid number from EOF and (b) be a bit more consistent with the character input function, where -1 is used for an "exception" of sorts. Would you be up for implementing that, and adding a page to the documentation that summarizes the behavior? I can also do the docs part if you'd like. Thanks so much for your help with this!

…

On Mon, Dec 9, 2024, 10:02 AM Sy ***@***.***> wrote: There isn't really any difference per se, because -1 and -2 are valid non-error inputs (well, not in this version, see #22). I can implement either. On Mon, Dec 9, 2024 at 7:41 PM Zeb Burke-Conte ***@***.***> wrote: > That makes sense. I think I'm convinced it is better to return a flag > value > in these cases. I'm not sure I like 0 being used for both. > > Is there any other reason you like 0, besides that it's what the reference > implementation does? Since the behavior is already so different, I think > I'd go for something like -1 on EOF, -2 on invalid number. > > On Sun, Dec 8, 2024, 8:33 PM Sy ***@***.***> wrote: > > > I don't think there is a way around that. The problem is that the > > alternative makes numeric input potentially dangerous. Consider working > > with input like "1\n23\n45\n". If reading a number after eof throws, the > > only way to work with this input is by avoiding numeric input and > parsing > > this by-character, which defeats the purpose of having two separate > input > > commands. > > > > — > > Reply to this email directly, view it on GitHub > > < > #23 (comment)>, > > > or unsubscribe > > < > https://github.com/notifications/unsubscribe-auth/ADF5EUFNMB4Z2VR6UXLGPST2EUMTLAVCNFSM6AAAAABSZKY5KOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRWHA3DSNBUGU> > > > . > > You are receiving this because you commented.Message ID: > > ***@***.***> > > > > — > Reply to this email directly, view it on GitHub > < #23 (comment)>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AJU2B76XUN2CO4XZUEHYVCD2EXB4JAVCNFSM6AAAAABSZKY5KOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRYGY2DSMJTGY> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADF5EUGCADINKCG7SU2YKTD2EXLM7AVCNFSM6AAAAABSZKY5KOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRYHE2DGNZXGM> . You are receiving this because you commented.Message ID: ***@***.***>

[sy-python]

I am not sure how do edit the docs, and I did implement the error codes

[zmbc]

Thanks so much! I haven't documented this well, but the docs are in Markdown in the docs subdirectory of the repo, and you should be able to preview changes with mkdocs serve, assuming you've done a dev install with Poetry.

Want to give it a try? Or, I think I can add onto your existing PR :)

[sy-python]

I will try it tomorrow when I have time :)