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


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
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


a

 contained string with the "+/" pattern.


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


</snip>
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


to

 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




there's

 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




there's

 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


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
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?



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