🚀 go-pugleaf

In article <451qot$lk6@tornews.torolab.ibm.com>, dmm@neutron.torolab.ibm.com (Dave Mooney) writes:
|> Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
|> > However, be warned that trailing spaces and tabs disable it as a line
|> > continuation character.  
|> 
|> Actually, trailing spaces and tabs *can* disable it as a line continuation
|> character (but don't have to), for the reason you mention below:
|> 
|> > note that the standard does not define
|> > how non-trivial end-of-line indicators are represented.  
|> 
|> An implementation could well define the end-of-line indicator to be "an
|> arbitrary number of spaces followed by a newline", so code that has those
|> trailing tabs and spaces is still conforming.  Note that this is how
|> implementations on record-oriented architectures like IBM big iron get
|> around the lack of a newline character.

Actually, they use a different loophole in the standard, but I take your
point.  If an implementation uses your escape, then either it has a major
effect on the handling of text files during execution or it requires
different text file semantics for compilation and execution.  Either of
those would be possible, if bizarre.

However, if I follow your logic to its conclusion, then a compiler that
forbids pre-processor directives to start in column 1 is conformant
(because an end-of-line indicator could be the longer of a newline or
newline+'#').  Now, THAT is something that people would object to :-)


Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679