search

catseye / FBBI

MIRROR of https://codeberg.org/catseye/FBBI : The Flaming Bovine Befunge-98 Interpreter.
https://catseye.tc/node/FBBI
Other
4 stars 1 forks source link

Inconsistent behaviour of wrapping in stringmode #2

Open j4james opened 7 years ago

j4james commented 7 years ago

Quoting from the section on Strings in the Funge-98 documentation:

In Funge-98 stringmode, spaces are treated "SGML-style"; that is, when any contiguous series of spaces is processed, it only takes one tick and pushes one space onto the stack. This introduces a small backward-incompatibility with Befunge-93; programs that have multiple spaces and/or wrap while in stringmode will have to be changed to work the same under Funge-98.

This suggests to me that strings that wrap around the playfield should push one space onto the stack when that wrapping occurs. If my understanding is correct, I would then expect the program below to output 32:

<@."

At least that's how most Befunge-98 implementations seem to interpret it. But in FBBI that code ends up outputting 60 (the ASCII value for <), since no space is pushed.

My first thought was that this was just a different interpretation of the spec, but the behaviour isn't consistent. If you add another line of content to the source that is wider the first line, then the behaviour suddenly changes.

<@."
xxxxx

Now FBBI will output 32 rather than 60, even though that second line should clearly have no effect on the result. This makes me think the original behaviour might well have been a bug.

As for fixing it, my first thought would be to remove the final ip_march call from the ip_backtrack function. That way you're guaranteed to execute at least one out-of-bounds step after a backtrack, and thus you're guaranteed a space will always be pushed. You shouldn't have to worry about too many spaces, since the '98 spacemode check already handles that. There may be other problems that arise from such a change, though.

GolfingSuccess commented 7 years ago

Now FBBI will output 32 rather than 60, even though that second line should clearly have no effect on the result. This makes me think the original behaviour might well have been a bug.

I think that's intentional, although I'm not really sure. The source code is rectangularized, so lines shorter than the longest line(s) are padded with spaces at the end.

j4james commented 7 years ago

The source code is rectangularized, so lines shorter than the longest line(s) are padded with spaces at the end.

But all memory in Funge-98 is already considered to contain spaces (at least until overwritten with something else). This is from the specification:

A Funge-98 program should also be able to rely on the memory mechanism acting as if a cell contains blank space (ASCII 32) if it is unallocated, and setting memory to be full of blank space cells upon actual allocation

And from the section on wrapping:

by default every cell in Funge-Space contains a space (32) character.

So "padding" a line with spaces shouldn't make any difference to the semantics of the program. Nor should writing a space into an uninitalised memory cell. In both cases, nothing in Funge-Space has been changed. The implementation details of the internal memory model shouldn't be a factor.