Re: [sv-bc] precedence of :/ vs. //

I meant: "://xxxx" would indeed be lexed as :/ followed by the lex of /xxxx"

Nikhil

Rishiyur S. Nikhil wrote:

> But removing comments is not blind-- it does take some account of
> tokenization.
> For example,
> a // inside a string does not begin a comment,
> a // inside an escaped identifier does not begin a comment
> etc.
>
> Many lexers indeed use a "maximum munch" principle, i.e., i.e.,
> continue gobbling characters as long as it legally extends the
> current token under consideration. By that principle,
> ://xxxx would indeed be lexed as :/ followed by a comment.
>
> Nikhil
>
> Brad Pierce wrote:
>
>> The // is not itself a token. The entire comment, including the //,
>> is a single token. This is specified in 2.1 of the V2K LRM. Likewise,
>> the /* and */ in a block comment are not tokens.
>>
>> So a line like
>>
>> ://xxxxxxxx
>>
>> is not ambiguous, because there is only one legal tokenization of it.
>>
>> The issue then is about unlikely constructs such as the following,
>> in which extra slashes have been added
>>
>> :///xxxxxxx
>>
>> In my opinion, this is still clearly a : token followed by a comment
>> token. Note that comments are not part of the BNF. Regardless of
>> how most current lexers are written, comments are conceptually stripped
>> out before any tokens are emitted to the parser.
>>
>> The main reason this is not done in practice is that there are
>> often nonstandard language extensions (pragmas) embedded in the
>> comments. (As an aside, note that if a // comment is included in
>> the text of a macro, it *must* be stripped out, pragma or not,
>> according to 19.3.1 of the V2K LRM. So if you want to embed a
>> pragma using a macro, it must be a block comment.)
>>
>> Conceptually, the line
>>
>> :///xxxxxxx
>>
>> should be preprocessed to
>> :
>>
>> There is still no real ambiguity. It's just a lexing issue.
>>
>> -- Brad
>>
>>
>> -----Original Message-----
>> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On Behalf Of
>> Hermann.Ilmberger@infineon.com
>> Sent: Thursday, August 26, 2004 2:39 AM
>> To: pgraham@cadence.com
>> Cc: sv-bc@eda.org
>> Subject: RE: [sv-bc] precedence of :/ vs. //
>>
>>
>>
>>>> However, if your tool has a Verilog2001 mode and a
>>>
>>>
>>> SystemVerilog mode,
>>>
>>>> the :// in your example would have to be preprocessed as
>>>> : // (2 tokens) for 2001, and as
>>>> :// (1 token) for SystemVerilog.
>>>
>>>
>>> What do you mean that "://" is one token in SystemVerilog? I don't
>>> see any "://" token in the lrm. (Or has one been added since 3.1a
>>> draft 6?)
>>
>>
>>
>> Sorry - I scanned one / to much. This all looks like smilies.
>> :// has to be scanned as
>> : // (2 tokens) for 2001, and as
>> :/ / (2 tokens) for SystemVerilog
>> when we assume C++ LRM rules.
>>
>>> The problem is that SystemVerilog needs to be backwards compatible
>>> (as much as possible) with standard Verilog. I ran across this "://"
>>> problem in an existing verilog test case.
>>
>>
>>
>> I had the same problem. :// is un-compatible, and if there is still a
>> possibility
>> we should find a better name which does not break old Verilog.
>> -Hermann
>>
>>
>>> The "///" problem wasn't an issue for C/C++ since "///" could never
>>> occur in a valid C program (except within a /* ... */ comment).
>>>
>>> Paul
>>>
>>
>>
>
>
Received on Fri Aug 27 09:45:06 2004