www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2660] New: Change #line to pragma(line)

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2660

           Summary: Change #line to pragma(line)
           Product: D
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: clugdbug yahoo.com.au


The #line special token sequence looks extremely foreign in the language.
Changing #line Integer FileSpec EndOfLine into:
pragma(line, Integer, FileSpec)
would free up the # character.


-- 
Feb 13 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2660





------- Comment #1 from shro8822 vandals.uidaho.edu  2009-02-13 11:47 -------

I rather expect that will never happen as the #line bit is there for
compatibility with the c preprocessed tool stack (lex, yacc, CPP and any other
pre existing tools/editrs that need to remap line numbers) 

In short, don't reinvent the wheel.


-- 
Feb 13 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2660





------- Comment #2 from ary esperanto.org.ar  2009-02-13 12:07 -------
But the #line is processed by the lexer, I don't see what that has to do with
lex, yacc and other CPP tools...

The problem with the pragma solution is that pragmas are processed during the
semantic pass, and line numbers are already assigned by then.

But I woudldn't mind the lexer peeking some tokens after "pragma" to see if
it's "pragma(line" to make this happen. Some "magic" in benefit of making a
programmer's life easy and making a character available for the language is
worth it.

The same goes for my idea to make version(D1), version(D2) be processed in the
lexical stage (to skip pieces of code so that you don't have to do the mixin
workaround). The only excuses for not doing this seems to be that it will make
the lexer a little harder for 3rd party tools to do. But: 1. most of the tools,
if not all of them, use DMD's front end, and 2. it's very easy compared to
other stuff that needs to be performed by a regular D compiler (mixins,
templates, etc.).


-- 
Feb 13 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2660





------- Comment #3 from shro8822 vandals.uidaho.edu  2009-02-13 13:30 -------
Take a look at what Lex/Yacc/Flex/Bison and a pile of other tools generate.
Anything that is copied from the input file into the output is prefaced with
#line so that errors point to the right place. I see no reason to break with
this convention as I rather suspect that there are other tools out there that
also leverage it.


-- 
Feb 13 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2660





------- Comment #4 from clugdbug yahoo.com.au  2009-02-16 07:08 -------
I rather expect that will never happen as the #line bit is there for

pre existing tools/editors that need to remap line numbers) But those tools normally create or consume C code. D isn't C, so I don't see how this is relevant. For example Java doesn't support #line as far as I know, so it has the same limitation. (C# does support it, but it also supports #if, #define, etc). Are there any such tools where it is relevant? --
Feb 16 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2660





------- Comment #5 from shro8822 vandals.uidaho.edu  2009-02-16 13:18 -------

I'll admit it is not public domain, but I have a tool for translating c# into D
that uses #line all over the place and a tool that takes a file with #line
directives and finds lines that assume a given file name/line number

I guess my point is that #line is a bit of a standard and I see no point in
breaking from it. Even getting another operator is a bit of a hard sell as the
only uses for # I known of are out-of-band annotations (C's usage and bash like
comments) so I would be hesitant to give it any other use.


-- 
Feb 16 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2660





------- Comment #6 from wbaxter gmail.com  2009-02-16 19:27 -------
(In reply to comment #5)
 I'll admit it is not public domain, but I have a tool for translating c# into D
 that uses #line all over the place and a tool that takes a file with #line
 directives and finds lines that assume a given file name/line number

Can't you just spend like 2 seconds changing that to look for pragma(line..) instead of #line?
 I guess my point is that #line is a bit of a standard and I see no point in
 breaking from it. Even getting another operator is a bit of a hard sell as the
 only uses for # I known of are out-of-band annotations (C's usage and bash like
 comments) so I would be hesitant to give it any other use.
 

I think here, too, removal of #line should be conditioned upon some agreement about what to do with it once it's free. --
Feb 16 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2660





------- Comment #7 from shro8822 vandals.uidaho.edu  2009-02-16 20:09 -------
(In reply to comment #6)
 
 Can't you just spend like 2 seconds changing that to look for pragma(line..)
 instead of #line?
 

That's not my point, my point is that there are tools in play that deal with #line and I rather suspect nothing at all to deal with pragma(). I see a cost to the switch and no gain.
 
 I think here, too, removal of #line should be conditioned upon some agreement
 about what to do with it once it's free.
 

I guess I'm saying the same thing, but with the added assertion that I don't think you will come up with something better to do with it --
Feb 16 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2660





------- Comment #8 from maxmo pochta.ru  2009-02-18 05:00 -------
AFAIK # is used as a prefix operator in miniD


-- 
Feb 18 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2660





------- Comment #9 from jarrett.billingsley gmail.com  2009-02-18 08:25 -------
Quite right.  It's borrowed from Lua and means "length" or "size".  Which, I
assume, was originally borrowed from math.


-- 
Feb 18 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2660





------- Comment #10 from bugzilla digitalmars.com  2009-02-20 21:15 -------
#line can be processed with a simple, stupid tool, but pragmas cannot be,
because they are recognized at much later stage.

The idea of recognizing pragma(line) as 'special' in the lexing stage is an
awful hack <g>.


-- 
Feb 20 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2660





------- Comment #11 from tomas famolsen.dk  2009-02-21 00:05 -------
clobbing up the # character like that is pretty aweful as well!


-- 
Feb 20 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2660





------- Comment #12 from clugdbug yahoo.com.au  2009-02-21 04:41 -------
Like Thomas, I think the existing #line is already a hack. The whole concept of
#line is not pretty. The fact that the # character used only in this one place
in the language is pretty hard to justify for such a tiny feature, IMHO. As far
as I can tell, any sequence of characters could be used for this purpose.

pragma(line) would be an even worse hack from the compiler-writers point of
view, since it's making two completely different things look the same, but is
it really important to the users to know have a strong visual clue of how this
feature is implemented?


-- 
Feb 21 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2660





------- Comment #13 from maxmo pochta.ru  2009-02-24 02:32 -------
D has entire namespace of tokens __*__ reserved for internal use. How about
using it? I don't know at which stage they are processed. They are documented
in lexical part of specs. How about this declaration:

SpecialTokenSequence:
        __assume_line__ Integer EndOfLine
        __assume_line__ Integer Filespec EndOfLine

Filespec:
        " Characters "

Any objections? I think, it's a trivial substitution.


-- 
Feb 24 2009