When describing the 'contract' between the fingerprint and the fingerprint user, one of the bullet points is:

When loaded, a fingerprint which implements A and B semantics should act something like:

But then no further copy follows that line. The earlier HTML version of the documentation had something like this:

save(A); bind(A, myAsemantic()); save(B); bind(B, myBsemantic());

The next point has the same issue:

When unloaded, the same fingerprint should act something like

And again no further copy. The earlier HTML documentation had:

restore(B); restore(A);

The E 'Erase mark' operation removes an already existing timer mark with the current IP's ID.

However, it is not defined whether it should reflect, or behave as no-op when such a mark was not created already using M beforehand.

In my subjective opinion, no-op fallthrough makes the most sense given that the end result would be the same in both cases (T reflecting), however, E reflecting with an empty mark would have a higher consistency with the behaviour of other instructions that reflect on failure.

The safest way to go about using HRTI in this case would be to make sure that E is never called before M (or twice after M), or by having a reflection-ignoring construct around E (for instance: 3j>z#E when entering at the 3 with a delta to the right).

(this issue is just a minor observation for anyone who is looking to use this specific fingerprint in their code and not a request for clarification)

I'm implementing Befunge-98 in Ruby.

The problem is that according to the Lahey-space wrapping the backtracking a long delta is not the same as circling around a sphere -- it is going to have a shift.
Also because of that it is not clear where it should stop on the other side in case, for example, when dx=0, dy>1 and the column starts lower than some another column. I.e. what is the "addressable space" -- if the program is 0001-p 001-0p, where is now the "least point which contains a non-space cell"? And what if I put 32 instead of 0?

In Trefunge-98 source, the ascii form feed increments the z coordinate, which is equivalent to a 'go low' instruction. This is all the specification says.

I'm imagining a 3-dimensional Funge-Space as a series of 2-dimensional Funge-Spaces placed on top of each other.
So is a plane at Z=1 in front of or behind a plane at Z=0?

I think it is behind, since that would make sense if this 'stack' of 2D planes was viewed from the top down, where higher z coordinates are lower on the stack. (i.e. the image on the right, which corresponds to regular 3-dimensional cartesian space rotated 180° around the X-axis)

South and North seem to be labeled with incorrect delta values (found here).

Everywhere else seems to indicate south is (0,1) and north is (0,-1).

In the Instruction Quick Reference table, both the Quit instruction and the East-West If instruction are missing their input parameter in the Before column (r for the former and b for the latter).

I suspect this data was lost in the conversion from HTML to markdown because it was certainly present in older versions of the documentation.

The program flow section states that h is delta <- (0,0,1) and l is delta <- (0,0,-1), whereas the quick reference states the opposite.

The algorithmic description of same-line wrapping can be described as
backtrack wrapping. It is more of interest to Funge interpreter
implementers than Funge programmers. However, it does describe exactly
how the wrapping acts in terms that a programmer can understand, so we
will include it here.

When the IP attempts to travel into the whitespace between the code and
the end of known, addressable space, it backtracks. This means that its
delta is reversed and it ignores (skips over without executing) all
instructions. Travelling thus, it finds the other 'edge' of code when
there is again nothing but whitespace in front of it. It is reflected
180 degrees once more (to restore its original delta) and stops ignoring
instructions. Execution then resumes normally - the wrap is complete.

It is easy to see at this point that the IP remains on the same line:
thus the name. (Also note that this never takes any ticks in regards
to multithreading, as would be expected from any wrapping process.)

This above is probably most confusing description I've ever read in a spec. And I've read quite a few specs in my life. Please help me understand it and may be improve it, so it's more accessible for everyone.

First of all it is not clear what is "whitespace" above. This word appears two times in the quoted section, and never again before or after in the specification. Without other guidance, we should assume conventional meaning, which is usually a character that represent horizontal or vertical space. In the context of the spec, my best guess, that this is a cell with a space character ASCII 32. If that's not the case, please clarify.

Next, "line" is mentioned in the quoted text, but I'm not sure how to connect this with the previous discussion of lines in the spec. My best guess is based on the following paragaph:

The source file begins at the origin of Funge-Space. Subsequent columns of characters increment the x coordinate, and subsequent lines increment the y coordinate (if one is present) and reset the x coordinate to zero. Subsequent lines in Unefunge are simply appended to the first, and the end of the source file indicates the end of the (single) line.

So I'm assuming that a line, is everything that has the same y coordinate as IP. If this is wrong, please clarify.

When the IP attempts to travel into the whitespace between the code and the end of known, addressable space, it backtracks.

Let's try to decompose this a bit. When IP "travels" it travels from the current node to the next node as specified by the delta. That next node contains a cell which may or may not contain a whitespace. The specification either assumes that it certainly does, or limits the description to the cases when it does. As far as I can see it, the prime case for wrapping, is when there next node does not exist at all because we reached the edge of addressable space. Similarly, it's not clear why would we want to wrap, if we has not reached the end of addressable space yet, on a white space. May be this too could be clarified?

It is easy to see at this point that the IP remains on the same line: thus the name.

This sound as complete non-sequitur. I can see why this may be true if the delta point along the line IP is currently on, but in any other case I cannot see how this could be true.

I feel that this section may benefit from better definition of terms it's using, and simply from better wording. Also it is very hard to see what the diagram is trying to demonstrate. May be a few words tying it to the text somehow could help?

And a small unrelated to the above suggestion: r seems to refer to "reverse" is some parts of the document and to "reflect" in others. I believe that consistency here, or a clear explanation what the relationship between "reflect" and "reverse" is would make the document less confusing. If "reflect" and "reverse" is the same thing, I would suggest choosing a single term (I would vote for "reverse") and use it through the document, not just as the keyword for r instruction, but as well for concepts explanation.

The spec doesn't explain some things in context of concurrent Funge. Especially which state is per thread and which is global. I'm specifically wondering about the stack stack: The spec does mention that each thread has it's own stack which gets copied when a thread is forked, but does each thread also have it's own stack stack? If yes, is the whole stack stack cloned on fork or only the TOSS?

In comparing the Funge-98 virtual machine to Befunge-93, the specification says:

Befunge-93 defines signed 32-bit stack cells and unsigned 8-bit Funge-Space cells.

However, that seems like a fairly dubious claim when the Befunge-93 documentation said nothing of the sort.

A Befunge-93 program is treated as an 80x25 torus ... of ASCII text.

Each command in Befunge-93 is a single character, as is the largest data unit that can be specified in the program source.

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 a char 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 as signed by default. You can confirm that to some extent by testing some of the older reference binaries that are still available online:

• quadium.net
• sourceforge.net

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 stack has signed 32-bit integers, and the memory matrix has signed bytes.

Something to note is that in bef-93 the grid data type is signed...

A better way to say this would be that -93 used a single signed byte for each memory cell in the program space, and that -97 uses a 4-byte signed doubleword.

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.

• Chris Lahey's Mandelbrot fractal generator
• Befunge Chess

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.

because pandoc unfixed it.