-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Befunge-93 cells were not unsigned #2
Comments
Indeed. It's a fairly dubious spec.
Well, that's a fairly strong claim! What behaviour do you see when you run them on an interpreter with an unsigned cell type, and on what basis do you say that that observed behaviour violates those programs' specs? clears throat Well anyway. Given the dozen-or-so questionable statements this document makes about the language it claims to define, I don't think it's worth worrying about any claims it may or may not have made in the past 18 years about any other languages it may or may not also make mention of. |
When executed on a signed interpreter, Lahey's Mandelbrot fairly closely resembles the ASCII rendering on Wikipedia, although further zoomed out. On an unsigned interpreter, it looks like a small pile of poo. Given that he described the program as 'a text version of the mandelbrot set', I think it's reasonable to assume that the former interpretation was more likely the intended one. As for the chess implementation, you're just going to have to take my word for it that in a typical game of chess, when the white player makes his opening move, it's not usual for his opponent to immediately collapse on the board and die. That's basically what happens when you try to run that chess program on an unsigned interpreter.
Not expecting you to fix anything if you don't want to. Just wanted to provide some documentation of the issue for others that might stumble across this page while looking for more information on Befunge. |
I suppose adding an ERRATA document to this repo, to include the information in this issue and in #5 in a non-Github-specific way, would not be unmeet. |
Also, reading this again, the original |
This error has been listed in the ERRATA document, which has now been released. Thank you for your report. Closing this issue. (If I investigate the signedness of chars in DICE C it will probably be something I do as part of Befunge-93 archaeology. But if I find out anything I'll try to remember to update this issue with it too.) |
Thanks for following up on this issue. Regarding DICE C, I did a bit of digging last night, and it turns out that the source code for the compiler has been made public, so you can download it from here: http://legacy.obviously.com/dice/ And if you have a look at the limits.h file in the include directory, you'll find the following defines:
This suggests to me that the char type was almost certainly signed, but I couldn't actually get it to compile anything to test for certain. It seems to require Amiga libs that aren't included, but maybe if you've got an old Amiga knocking around somewhere you might get further with it than me. Also note that the copyright date on that file was 1992, so it seems likely this would have been close to the version you were using at the time that Befunge-93 was originally developed. |
In comparing the Funge-98 virtual machine to Befunge-93, the specification says:
However, that seems like a fairly dubious claim when the Befunge-93 documentation said nothing of the sort.
There's no mention of whether the data units are signed or unsigned.
Looking at the source of the reference implementation, the code page is defined as a
char
array, and in ANSI C it's left up to the compiler implementation to decide whether achar
is signed or unsigned. So at best, then, you could maybe say the signed state of the cell type was undefined.However the DOS version of the reference implementation was built with Borland C++, and according to their documentation (see page 158), they interpret the
char
type assigned
by default. You can confirm that to some extent by testing some of the older reference binaries that are still available online:So what is the source of the claim that the cell type was unsigned? Was the original Amiga version of the interpeter built with a compiler that used an unsigned char?
Certainly by the time the Funge-97 and Funge-98 specs were being developed, it seemed generally accepted that playfield cells were signed. Some quotes from the Befunge mailing list:
The last quote was suggested copy for the '97 version of the spec, and that even seemed to be something you agreed with at the time (your reply was: "OK, it'll say it something like that.").
Furthermore, if you look at some of the early examples of Befunge programs, some of them just wouldn't work if the cell type was unsigned.
Admittedly the latter was written several years after the Funge-98 spec was finalised, but it's got to be one of the classics of Befunge. If an interpreter can't run Befunge Chess, it's just not a real Befunge interpreter as far as I'm concerned.
Anyway, this obviously makes no difference to the Funge-98 language itself, but if the spec is going to include commentary on Befunge-93 as well, it would be good to get those facts straight.
The text was updated successfully, but these errors were encountered: