www.digitalmars.com         C & C++   DMDScript  

D - [BUG] minor: /+ +/ comment terminated by a string

reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
Probably a minor issue:

If you use a  /+  +/ style comment, it will be terminated early if there's a
contained string with the "+/" pattern.

That is: the comment scanner doesn't know about strings.

- Kris
Apr 10 2004
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
news:c59jq1$1eb8$1 digitaldaemon.com...
 Probably a minor issue:

 If you use a  /+  +/ style comment, it will be terminated early if there's

 contained string with the "+/" pattern.

 That is: the comment scanner doesn't know about strings.

That's consistent with /* and */ in D as well as in C++.
Apr 10 2004
next sibling parent reply Juan C <Juan_member pathlink.com> writes:
But did you decide that this is how it _should_ be?
Being consistent with C/C++ should not be a design goal -- you are trying to
create a *better* language, right?

<snip>
 If you use a  /+  +/ style comment, it will be terminated early if there's

 contained string with the "+/" pattern.


Apr 10 2004
parent "Walter" <walter digitalmars.com> writes:
"Juan C" <Juan_member pathlink.com> wrote in message
news:c59q9a$1nlv$1 digitaldaemon.com...
 But did you decide that this is how it _should_ be?

Yes.
 Being consistent with C/C++ should not be a design goal -- you are trying

 create a *better* language, right?

I've seen this particular issue on comments debated years ago, and the end result was neither side had a compelling argument. So I'll go with compatibility as the tipping factor.
Apr 10 2004
prev sibling parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
I figured so, but wasn't sure if that was the design goal. Would certainly
make the parser faster in that particular area.

I guess if we really want to avoid these kinds of gotcha's, then we should
use version{} instead ... yes?  If so, then perhaps /+  +/ is somewhat
redundant?

- Kris


"Walter" <walter digitalmars.com> wrote in message
news:c59nvm$1k9a$1 digitaldaemon.com...
 "Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
 news:c59jq1$1eb8$1 digitaldaemon.com...
 Probably a minor issue:

 If you use a  /+  +/ style comment, it will be terminated early if


 a
 contained string with the "+/" pattern.

 That is: the comment scanner doesn't know about strings.

That's consistent with /* and */ in D as well as in C++.

Apr 10 2004
parent J C Calvarese <jcc7 cox.net> writes:
In article <c59qil$1o1d$1 digitaldaemon.com>, Kris says...
I figured so, but wasn't sure if that was the design goal. Would certainly
make the parser faster in that particular area.

I guess if we really want to avoid these kinds of gotcha's, then we should
use version{} instead ... yes?  

Yes, if you're worried about this issue, then use version().
If so, then perhaps /+  +/ is somewhat
redundant?

/+ +/ comes in real handy for me for quick trials when I'm trying to chase down a bug or thinking about making major changes. I don't have too many "/+" enclosed in strings in my code. I would comment-out that line with a "//" instead of nested comments in that situation. (Uncommon solutions are appropriate for uncommon situations.) If you don't find nested comments useful, then don't use them. JC
- Kris


"Walter" <walter digitalmars.com> wrote in message
news:c59nvm$1k9a$1 digitaldaemon.com...
 "Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
 news:c59jq1$1eb8$1 digitaldaemon.com...
 Probably a minor issue:

 If you use a  /+  +/ style comment, it will be terminated early if


 a
 contained string with the "+/" pattern.

 That is: the comment scanner doesn't know about strings.

That's consistent with /* and */ in D as well as in C++.


Apr 10 2004
prev sibling parent reply Dave Sieber <dsieber spamnot.sbcglobal.net> writes:
"Kris" <someidiot earthlink.dot.dot.dot.net> wrote:

 Probably a minor issue:
 
 If you use a  /+  +/ style comment, it will be terminated early if
 there's a contained string with the "+/" pattern.
 
 That is: the comment scanner doesn't know about strings.

That behavior is in the spec, under "Lexical": "Comment processing conceptually happens before tokenization. This means that embedded strings and comments do not prevent recognition of comment openings and closings" Odd timing for your post -- I just implemented that behavior in my D lexer this morning :-) -- dave
Apr 10 2004
parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
I should learn to read :-)

"Dave Sieber" <dsieber spamnot.sbcglobal.net> wrote in message
news:Xns94C7C76FD2F43dsiebersbc 63.105.9.61...
 "Kris" <someidiot earthlink.dot.dot.dot.net> wrote:

 Probably a minor issue:

 If you use a  /+  +/ style comment, it will be terminated early if
 there's a contained string with the "+/" pattern.

 That is: the comment scanner doesn't know about strings.

That behavior is in the spec, under "Lexical": "Comment processing conceptually happens before tokenization. This means that embedded strings and comments do not prevent recognition of comment openings and closings" Odd timing for your post -- I just implemented that behavior in my D lexer this morning :-) -- dave

Apr 10 2004
parent reply Dave Sieber <dsieber spamnot.sbcglobal.net> writes:
"Kris" <someidiot earthlink.dot.dot.dot.net> wrote:

 I should learn to read :-)

I wouldn't sweat it -- there's a lot to learn :-) But I'm curious -- does your editor do syntax highlighting for D, and if so, did it highlight the comment correctly? -- dave
Apr 10 2004
parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
I'm using a combination of Epsilon (Emacs), and VC6.0. As you might expect,
neither show any sign of doing anything with the D-specific comments,
although they happily highlight D source as they would C++.

I could probably rattle up some additional EEL code for Epsilon, but it'll
never be quite as nifty as what you're working on ...

- Kris


"Dave Sieber" <dsieber spamnot.sbcglobal.net> wrote in message
news:Xns94C7DB2924634dsiebersbc 63.105.9.61...
 "Kris" <someidiot earthlink.dot.dot.dot.net> wrote:

 I should learn to read :-)

I wouldn't sweat it -- there's a lot to learn :-) But I'm curious -- does your editor do syntax highlighting for D, and if so, did it highlight the comment correctly? -- dave

Apr 10 2004
parent reply Dave Sieber <dsieber spamnot.sbcglobal.net> writes:
"Kris" <someidiot earthlink.dot.dot.dot.net> wrote:

 I'm using a combination of Epsilon (Emacs), and VC6.0. As you might
 expect, neither show any sign of doing anything with the D-specific
 comments, although they happily highlight D source as they would C++.
 
 I could probably rattle up some additional EEL code for Epsilon, but
 it'll never be quite as nifty as what you're working on ...

Right, so you don't get comment coloring at all if you use /+ +/ :-( LOL -- The line above just gave me a funny idea, to provide specific colors for certain emoticons, such as :-), :-(, and like that. For that matter, I could highlight certain words/phrases found frequently in comments, such as "KLUDGE", "BUG", "WALTER ROCKS", or "DAMN YOU MICROSOFT". And to make it complete, I could make BOLD BLINKING TEXT if I find any hungarian-style identifiers :-) -- dave
Apr 10 2004
next sibling parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
Cool!

I was gonna' suggest that you highlight the "enabled" version{} block or
blocks, cos' I imagine you're parsing all that stuff. Does the environment
you're working in support lifecycle state?

BTW; it might be a laugh to see the regex for recognizing Hungarian-notation
<g>

- Kris

"Dave Sieber" <dsieber spamnot.sbcglobal.net> wrote in message
news:Xns94C7EDDFB1E4dsiebersbc 63.105.9.61...
 "Kris" <someidiot earthlink.dot.dot.dot.net> wrote:

 I'm using a combination of Epsilon (Emacs), and VC6.0. As you might
 expect, neither show any sign of doing anything with the D-specific
 comments, although they happily highlight D source as they would C++.

 I could probably rattle up some additional EEL code for Epsilon, but
 it'll never be quite as nifty as what you're working on ...

Right, so you don't get comment coloring at all if you use /+ +/ :-( LOL -- The line above just gave me a funny idea, to provide specific

 for certain emoticons, such as :-), :-(, and like that.  For that matter,

 could highlight certain words/phrases found frequently in comments, such

 "KLUDGE", "BUG", "WALTER ROCKS", or "DAMN YOU MICROSOFT". And to make it
 complete, I could make BOLD BLINKING TEXT if I find any hungarian-style
 identifiers :-)

 --
 dave

Apr 10 2004
parent Dave Sieber <dsieber spamnot.sbcglobal.net> writes:
"Kris" <someidiot earthlink.dot.dot.dot.net> wrote:

 I was gonna' suggest that you highlight the "enabled" version{} block
 or blocks, cos' I imagine you're parsing all that stuff. Does the
 environment you're working in support lifecycle state?

I had thought of that, because MS does it with their C# editor, so it should be doable. But it would have to know which -version switch you want to highlight, or if it's a debug build, for instance. My first goal is to get basic syntax highlighting working, then add that kind of functionality step by step.
 
 BTW; it might be a laugh to see the regex for recognizing
 Hungarian-notation <g>

You can define new color classes, and then attach them to token types. Since you typically scan symbols for keywords vs. identifiers, you can also check for other words or spellings, etc. But maybe that should be in a later version, though :-) -- dave
Apr 11 2004
prev sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Dave Sieber wrote:

[...]
 For that matter, I 
 could highlight certain words/phrases found frequently in comments

VIM does that since a long time. Apropos how did you code your lexer for recognizing correctly `[2..4]', `[cast(int)2...4]', `[x...y]' and the like? So long!
Apr 11 2004
parent Dave Sieber <dsieber spamnot.sbcglobal.net> writes:
Manfred Nowak <svv1999 hotmail.com> wrote:

 VIM does that since a long time.

Yes, it's not uncommon. I was really just joking :-)
 Apropos how did you code your lexer
 for recognizing correctly `[2..4]', `[cast(int)2...4]', `[x...y]' and
 the like? 

For tricky things like these, I looked at how Walter did it in his front- end, since the editor should reflect the syntax just as the compiler would see it. The first example is legal, but the last two produce syntax errors, because, while "..." is a legal token itself, it can't be used in an array slicing context. In the second example, Walter's lexer detects this as an error because when he begins parsing a number and encounters '.', he looks ahead to see if the next char is also '.', in which case he backs out because ".." is illegal in a float, but is a valid token otherwise. When he backs out he then sees the third '.', and it's illegal in its context. In the third example, he sees "..." as a token right after the "x", but it too is in an illegal context. Syntactically they are all legal, so lexing doesn't produce errors. It's the semantic parsing that detects incorrect usage. As far as lexing and parsing of tricky contructs like the above, my own philosophy is that it's more important simply to be consistent with the errors rather than trying to deduce what the most logical interpretation is. In cases where the interpretation could go either way, I would prefer myself to write it explicitly clear, as in: [cast(int) 2. .. 4] Even if I am clear on how D might parse "2...4", the next guy working on the code might not be. After decades of errors and misinterpretation of code in our industry (something C++ specializes in :-), we should realize that depending on everyone's (and the compiler's) understanding of and agreement on the interpretation of tricky contructs is a dubious practice. </soapbox> <G> -- dave
Apr 11 2004