Re: #line 0.000000oo

[Paul Eggert]

> From: Akim Demaille <address@hidden>
> Date: 14 Nov 2002 11:12:31 +0100
> 
> %line is really immaterial to the grammar itself.

True.

> It's another layer, and as such, I tend to think that it is a good
> thing to move it elsewhere: #.

I agree with the "moving it elsewhere" part, but I'm not sure that I
agree with the plain "#" part, as "#" already has a specific meaning
in C code.  I see the following possible approaches:

 1. Bison's #line directive cannot occur in C code; any such #line
    directives are simply sent on to the C compiler.  This is the
    current solution, but it is unsatisfactory for reasons already
    discussed.

 2. Bison's #line directive can occur in C code.  It is upward
    compatible with the C #line, including all the backslash-newline
    processing, comments, etc.  (POSIX requires that it be upward
    compatible.)  That is a real pain, since the C syntax is so
    tricky.

 3. The Bison preprocessor directives use some other escape sequence,
    one that cannot occur in actual Yacc grammars.  In the rest of
    this discussion I'll assume the escape sequence "#%", and use
    "#%line", "#%if", "#%endif", etc.  I'd prefer "%#line"
    etc. esthetically, but "%#line" can occur in strictly conforming
    (albeit diabolic) C code.

(3) is by far the cleanest solution, because it makes it clear to the
user that two preprocessors are involved, and it avoids confusion
about which preprocessor is being invoked.

> I must be missing something, but it seems to me that a
> very [rigid] `#line INT STRING' is not that hard to follow.

It's easy to read, but it's hard to type in some cases.  I use Emacs,
and I can't easily tell whether the line has trailing white space,
unless I make a special effort to.  Likewise for tabs versus spaces.
I shouldn't have to worry about such details.

> |   ^{w}*"%line"{w}+{int}{w}*("\""(\\.|[^\n\"\\])*"\""{w}*)?"\n"
> | 
> | where {w} is any horizontal white space character ([ \f\t\v]).
> 
> I'm fine with this implementation.  But I'm still reluctant onto %line
> vs. #line.  They do not belong to the same worlds.

OK, how about if we use the following regular expression instead?

"#%line"{w}+{int}{w}*("\""(\\.|[^\n\"\\])*"\""{w}*)?"\n"

This directive specifies the line position of the first character
immediately after the newline.  The column number is set to 1.  The
file name's escape sequences are interpreted as in Standard C; if
omitted, the previous file name is used.  However, unlike Standard C,
backslash-newline is not allowed in the file name, and trigraphs are
not treated specially.

The #%line directive cannot be inserted into comments, string
literals, or character constants.  Aside from its effect on line and
column counting, it is lexically equivalent to white space.

This is the same basic idea as my previous proposal, except it uses
"#%line" instead of ^{w}*"%line".