Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000715Core InformSpacing and printingpublic2011-08-08 18:082014-05-07 07:33
Reporterzarf 
Assigned Tograham 
PrioritynormalSeveritymildReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version6G60 
Target VersionFixed in Version6L02 
Summary0000715: Quoted strings containing literal linebreaks are treated inconsistently
DescriptionThere 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.)

Minimal Source Text To Reproduce
"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.";
---------------------
TagsNo tags attached.
Effect(serious/mild) Game compiles but misbehaves
Attached Files

- Relationships

-  Notes
(0002418)
graham (administrator)
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.

- Issue History
Date Modified Username Field Change
2011-08-08 18:08 zarf New Issue
2011-09-01 09:31 EmacsUser Status new => confirmed
2014-02-01 03:28 graham Note Added: 0002418
2014-02-01 03:28 graham Status confirmed => resolved
2014-02-01 03:28 graham Resolution open => fixed
2014-02-01 03:28 graham Assigned To => graham
2014-05-07 07:32 jmcgrew Fixed in Version => 6L02
2014-05-07 07:33 jmcgrew Status resolved => closed


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker