MantisBT - Core Inform
View Issue Details
0000715Core InformSpacing and printingpublic2011-08-08 18:082014-05-07 07:33
zarf 
graham 
normalmildalways
closedfixed 
6G60 
6L02 
(serious/mild) Game compiles but misbehaves
0000715: Quoted strings containing literal linebreaks are treated inconsistently
There are several parts to this, some of which may be "works as intended", but (I think) not all. Consider the source code below and its output.

Examples 1 and 2 demonstrate that a double linebreak (in a quoted string) is converted to a paragraph break in the output, *as long as* the following line of text is not indented. (That is, the "1b" and "2b" begin in column zero.) The indentation of the blank line does not matter -- that's the difference between example 1 and example 2 -- you get the same result.

Example 3 is what happens if the following line of text *is* indented. Two line breaks and a tab (in the I7 code) are converted to *one* line break and a tab (in the I6 code); the I6 compiler then converts this to one line break and a space character. This is surprising and almost certainly not what the author wants.

Note that if the author naively hits the Return key twice while typing this source code, he will wind up with example 3. That's because of the IDE's auto-indentation. You have to consciously delete tab characters to get back to the (probably desired) example 1.

Example 4 is what happens if you hit the Return key *once*. The literal line break (and tab character) are swallowed and converted to a space character. This may be the compiler's intended behavior, but I think it is surprising in light of examples 1/2.

Example 5 shows that for the single-line-break case, it *doesn't* matter whether the following line of text is indented or not. Examples 4 and 5 generate the same output. However, the generated I6 code reveals that this is sort of accidental -- the I7 compiler is generating different I6 string constants for these cases. They then get regularized by the I6 compiler.

(This is *not* what happens in ex 1/2; there the I7 compiler generates "^" characters, as expected for I6 source code.)

(Footnote: Printing a tab character is illegal in Glulx and questionable in Zcode. The I6 compiler takes a string of literal tabs and newlines in the I6 source and compiles it as a single space.)

So, questions:

- Should a single line break be swallowed, as in ex 4/5? If so, document it.
-- Either way, the generated I6 string constants should not contain literal tabs and newlines. It's not broken (because I6 handles these consistently) but it's ugly and confusing.
- The behavior of example 3 really should be changed. The indentation before "3b" should be ignored, and the double line break preserved, producing a result identical to ex 1/2. (And again, no literal tab or newline.)

"Test Case" by Andrew Plotkin.

The Kitchen is a room.

When play begins:
[Five distinct examples follow!]
say "1a.

1b.";
say "2a.

2b.";
say "3a.

3b.";
say "4a.
4b.";
say "5a.
5b.";

---------------------
[Generates output:]
---------------------
1a.

1b.
2a.

2b.
3a.
 3b.
4a. 4b.
5a. 5b.

---------------------
[I6 code:]
---------------------
Constant SC_11 = "1a.^^1b.";
Constant SC_12 = "2a.^^2b.";
Constant SC_13 = "3a.^ 3b.";
Constant SC_14 = "4a. 4b.";
Constant SC_15 = "5a.
5b.";
---------------------
No tags attached.
Issue History
2011-08-08 18:08zarfNew Issue
2011-09-01 09:31EmacsUserStatusnew => confirmed
2014-02-01 03:28grahamNote Added: 0002418
2014-02-01 03:28grahamStatusconfirmed => resolved
2014-02-01 03:28grahamResolutionopen => fixed
2014-02-01 03:28grahamAssigned To => graham
2014-05-07 07:32jmcgrewFixed in Version => 6L02
2014-05-07 07:33jmcgrewStatusresolved => closed

Notes
(0002418)
graham   
2014-02-01 03:28   
I really believed that I had proved the lexer correct some time around 2008, but apparently not, because the handling of (3) was not what I intended. This is now fixed, and they now generate

"1a.^^1b."

"2a.^^2b."

"3a.^^3b."

"4a. 4b."

"5a. 5b."

And tabs and newlines are now never passed through into I6 strings.