Interesting comment behaviour

[Dave Woodman]

An interesting behaviour of block comments that bit me just recently, posted here in the hope of sparing the others the unexpected compile failure.

 

Take the following abstracted example:-

 

say "/*"

 

say "OK"

 

Compiles, runs, all is well

 

Now comment out the first “say” with a block comment

 

/*

say "/*"

*/

 

say "OK"

 

Now try compiling – whoops “Error: Unmatched block comment start”

 

Now, consulting the NRL reveals that this behaviour is implied, even if surprising:-

 

“A block comment is started by the sequence of characters “/*”, and is ended by the

same sequence reversed, “*/”. Within these delimiters any characters are allowed

(including quotes, which need not be paired). Block comments may be nested, which

is to say that “/*” and “*/” must pair correctly. Block comments may be anywhere,

and may be of any length. When a block comment is found, it is treated as though it

were a blank (which may then be removed, if adjacent to a special character).”

 

So, a quote within a comment cannot be assumed to be correct, and nested comments are allowed, so the behaviour is correct.

 

Just a small point of note,

 

                Dave.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

+1 ... Thomas.

I did already propose to process the *quoted* literals '/*', '*/', "/*", "*/" in a special way in Rexx/NetRexx comments,
years ago, cannot recall where (comp.lang.rexx, RexxLa, ...?) as this is a common problem in all Rexx Dialects (NetRexx included)

Dave, currently the *ONLY* solution is to define those Tokens at the start of the Program, e.g.:

   SOC = "/*"  -- SOC ::= Start of Comment
   EOC = "*/"  -- EOC ::= End of Comment

and use those ACRONYMS then in your actual Code...

Have a good weekend! Thomas.
=============================================================================
 
Am 24.11.2012 00:39, schrieb Dave Woodman:

An interesting behaviour of block comments that bit me just recently, posted here in the hope of sparing the others the unexpected compile failure.

 

Take the following abstracted example:-

 

say "/*"

 

say "OK"

 

Compiles, runs, all is well

 

Now comment out the first “say” with a block comment

 

/*

say "/*"

*/

 

say "OK"

 

Now try compiling – whoops “Error: Unmatched block comment start”

 

Now, consulting the NRL reveals that this behaviour is implied, even if surprising:-

 

“A block comment is started by the sequence of characters “/*”, and is ended by the

same sequence reversed, “*/”. Within these delimiters any characters are allowed

(including quotes, which need not be paired). Block comments may be nested, which

is to say that “/*” and “*/” must pair correctly. Block comments may be anywhere,

and may be of any length. When a block comment is found, it is treated as though it

were a blank (which may then be removed, if adjacent to a special character).”

 

So, a quote within a comment cannot be assumed to be correct, and nested comments are allowed, so the behaviour is correct.

 

Just a small point of note,

 

                Dave.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[billfen]

Not the *ONLY* solution, since "say '/' || '*' " can be used.

Note that the error will still occur if the SOC line (only) is commented out.  To be bullet proof
    SOC = '/' || '*' -- etc should be used

A useful footnote in the language reference might be something like "The use of quoted string literals containing the sequences '/*' or '*/' should be avoided."

On 11/23/2012 11:28 PM, Thomas Schneider wrote:

+1 ... Thomas.

I did already propose to process the *quoted* literals '/*', '*/', "/*", "*/" in a special way in Rexx/NetRexx comments,
years ago, cannot recall where (comp.lang.rexx, RexxLa, ...?) as this is a common problem in all Rexx Dialects (NetRexx included)

Dave, currently the *ONLY* solution is to define those Tokens at the start of the Program, e.g.:

   SOC = "/*"  -- SOC ::= Start of Comment
   EOC = "*/"  -- EOC ::= End of Comment

and use those ACRONYMS then in your actual Code...

Have a good weekend! Thomas.
=============================================================================
 
Am 24.11.2012 00:39, schrieb Dave Woodman:

An interesting behaviour of block comments that bit me just recently, posted here in the hope of sparing the others the unexpected compile failure.

 

Take the following abstracted example:-

 

say "/*"

 

say "OK"

 

Compiles, runs, all is well

 

Now comment out the first “say” with a block comment

 

/*

say "/*"

*/

 

say "OK"

 

Now try compiling – whoops “Error: Unmatched block comment start”

 

Now, consulting the NRL reveals that this behaviour is implied, even if surprising:-

 

“A block comment is started by the sequence of characters “/*”, and is ended by the

same sequence reversed, “*/”. Within these delimiters any characters are allowed

(including quotes, which need not be paired). Block comments may be nested, which

is to say that “/*” and “*/” must pair correctly. Block comments may be anywhere,

and may be of any length. When a block comment is found, it is treated as though it

were a blank (which may then be removed, if adjacent to a special character).”

 

So, a quote within a comment cannot be assumed to be correct, and nested comments are allowed, so the behaviour is correct.

 

Just a small point of note,

 

                Dave.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2793 / Virus Database: 2629/5893 - Release Date: 11/13/12
Internal Virus Database is out of date.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[rvjansen]

Dave,

thanks for mentioning this. Somehow it strikes me as wrong; it also has
consequences for syntax colouring applications that need to show that
this is invalid - at least will not compile as most people would hope it
does.

I see that even -- say '/*' triggers the issue. I will be opening a
kenai issue later and we'll see if it gathers votes; when it does, we
might reconsider. I doubt that changing this will lead to the breakage
of many existing programs - those are not compiling programs. Usage of
the feature seems esoteric.

best regards,

René.


On 2012-11-24 00:39, Dave Woodman wrote:

> An interesting behaviour of block comments that bit me just recently,
> posted here in the hope of sparing the others the unexpected compile
> failure.
>
> Take the following abstracted example:-
>
> say "/*"
>
> say "OK"
>
> Compiles, runs, all is well
>
> Now comment out the first "say" with a block comment
>
> /*
>
> say "/*"
>
> */
>
> say "OK"
>
> Now try compiling - whoops "Error: Unmatched block comment start"
>
> Now, consulting the NRL reveals that this behaviour is implied, even
> if surprising:-
>
> "A block comment is started by the sequence of characters "/*", and
> is ended by the
>
> same sequence reversed, "*/". Within these delimiters any characters
> are allowed
>
> (including quotes, which need not be paired). Block comments may be
> nested, which
>
> is to say that "/*" and "*/" must pair correctly. Block comments may
> be anywhere,
>
> and may be of any length. When a block comment is found, it is
> treated as though it
>
> were a blank (which may then be removed, if adjacent to a special
> character)."
>
> So, a quote within a comment cannot be assumed to be correct, and
> nested comments are allowed, so the behaviour is correct.
>
> Just a small point of note,
>
>  Dave.
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[rickmcguire]

Good luck with not breaking any programs.  Implementing this would require some syntax awareness within comments, but the use of contractions such as "don't", etc. would seriously confuse the issue.  

Rick

On Tue, Nov 27, 2012 at 10:27 AM, rvjansen <[hidden email]> wrote:

Dave,

thanks for mentioning this. Somehow it strikes me as wrong; it also has consequences for syntax colouring applications that need to show that this is invalid - at least will not compile as most people would hope it does.

I see that even -- say '/*' triggers the issue. I will be opening a kenai issue later and we'll see if it gathers votes; when it does, we might reconsider. I doubt that changing this will lead to the breakage of many existing programs - those are not compiling programs. Usage of the feature seems esoteric.

best regards,

René.

On 2012-11-24 00:39, Dave Woodman wrote:

An interesting behaviour of block comments that bit me just recently,
posted here in the hope of sparing the others the unexpected compile
failure.

Take the following abstracted example:-

say "/*"

say "OK"

Compiles, runs, all is well

Now comment out the first "say" with a block comment

/*

say "/*"

*/

say "OK"

Now try compiling - whoops "Error: Unmatched block comment start"

Now, consulting the NRL reveals that this behaviour is implied, even
if surprising:-

"A block comment is started by the sequence of characters "/*", and
is ended by the

same sequence reversed, "*/". Within these delimiters any characters are allowed

(including quotes, which need not be paired). Block comments may be
nested, which

is to say that "/*" and "*/" must pair correctly. Block comments may
be anywhere,

and may be of any length. When a block comment is found, it is
treated as though it

were a blank (which may then be removed, if adjacent to a special character)."

So, a quote within a comment cannot be assumed to be correct, and
nested comments are allowed, so the behaviour is correct.

Just a small point of note,

 Dave.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[rvjansen]

Wouldn't this rather be the opposite - not looking at any syntax while
in a comment?

I imagine that language processors that do not suffer from this, have a
state 'in-comment' that starts after the first /* and scans until the
last */ - at least that is the definition of 'comment' that I would
expect.

We can also let it be and limit this to just ignore every line that is
prefixed by -- we do not have any problem to 'block comment' any number
of lines. (line defined as something that ends in at least a cr). I
routinely block out code but fortunately I don't comment as much - only
on separate lines.

I would be seriously surprised if someone depended on this behavior -
though I agree that has no relationship to the chance of breaking things
while fixing them.

A separate stage with Antlr's nested multiline comment algoritm would
do the trick I guess, but it would be much more desirable to have this
in the standard parser.
This works in antlr:

// ANTLR 3
NESTED_ML_COMMENT
    :   '/*'
     (options {greedy=false;} : (NESTED_ML_COMMENT | .))*
         '*/' {$channel=HIDDEN;}    ;
.

I am curious how Bill solved this in the Eclipse IDE and if it flags
the noncompilability in the coloring to match the result. I'll check
when I am near a real computer.

best regards,

René.



On 2012-11-27 16:43, Rick McGuire wrote:

> Good luck with not breaking any programs.  Implementing this would
> require some syntax awareness within comments, but the use of
> contractions such as "don't", etc. would seriously confuse the issue.
>  
>
> Rick
>
> On Tue, Nov 27, 2012 at 10:27 AM, rvjansen <[hidden email]> wrote:
>
>> Dave,
>>
>> thanks for mentioning this. Somehow it strikes me as wrong; it also
>> has consequences for syntax colouring applications that need to show
>> that this is invalid - at least will not compile as most people would
>> hope it does.
>>
>> I see that even -- say '/*' triggers the issue. I will be opening a
>> kenai issue later and we'll see if it gathers votes; when it does, we
>> might reconsider. I doubt that changing this will lead to the breakage
>> of many existing programs - those are not compiling programs. Usage of
>> the feature seems esoteric.
>>
>> best regards,
>>
>> René.
>>
>> On 2012-11-24 00:39, Dave Woodman wrote:
>>
>>> An interesting behaviour of block comments that bit me just
>>> recently,
>>> posted here in the hope of sparing the others the unexpected compile
>>> failure.
>>>
>>> Take the following abstracted example:-
>>>
>>> say "/*"
>>>
>>> say "OK"
>>>
>>> Compiles, runs, all is well
>>>
>>> Now comment out the first "say" with a block comment
>>>
>>> /*
>>>
>>> say "/*"
>>>
>>> */
>>>
>>> say "OK"
>>>
>>> Now try compiling - whoops "Error: Unmatched block comment start"
>>>
>>> Now, consulting the NRL reveals that this behaviour is implied, even
>>> if surprising:-
>>>
>>> "A block comment is started by the sequence of characters "/*", and
>>> is ended by the
>>>
>>> same sequence reversed, "*/". Within these delimiters any characters
>>> are allowed
>>>
>>> (including quotes, which need not be paired). Block comments may be
>>> nested, which
>>>
>>> is to say that "/*" and "*/" must pair correctly. Block comments may
>>> be anywhere,
>>>
>>> and may be of any length. When a block comment is found, it is
>>> treated as though it
>>>
>>> were a blank (which may then be removed, if adjacent to a special
>>> character)."
>>>
>>> So, a quote within a comment cannot be assumed to be correct, and
>>> nested comments are allowed, so the behaviour is correct.
>>>
>>> Just a small point of note,
>>>
>>>  Dave.
>>>
>>> _______________________________________________
>>> Ibm-netrexx mailing list
>>> [hidden email]
>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ [1]
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ [1]
>
>
>
> Links:
> ------
> [1] http://ibm-netrexx.215625.n3.nabble.com/
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Mike Cowlishaw]

René,  I suspect there is some confusion/cross-purpose about what 'this
behaviour' is.

In Rexx and NetRexx, block comments (/* .... */) nest.  This allows one to
'comment out' a block of code of any length and complexity thus:

 /* Ignore this test code
     test code etc. /* and comments */
     and more /* and more comments /* perhaps also with nested comments and code
*/ */
     /* end of test code */
 */

All of which works very well in almost all cases (one can comment out stuff
which includes commented-out stuff, and so on).  

The 'problem' occurs when a sequence such as

  */

or

  /*

appears in a string (or in a line comment) within a chunk of code that is being
'commented out'.  In these (very rare) cases the block comment will be ended
prematurely (or a new one will be started), causing confusion.

Since, by definition, a comment can contain any sequence of characters there is
no reason to assume that the contents might be 'code' -- so there is no reason
to interpret '*/' as though it might be code. It might be just an example within
a comment.  As might be the sequence '/*' (with or without the quotes).

In short .. inside comments, comment rules apply, not code rules.  Applying code
rules within comments will most surely break many programs.  In contrast the
comment rules are clean and simple, and in the rare cases when there is an
embedded /* or */ this is rapidly discovered.

Of course, a compiler could give a helpful warning ("this looks as though you
might have an embedded string literal that ends the comment") .. but that's very
different from changing the parsing rules.

Mike

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of rvjansen
> Sent: 27 November 2012 16:29
> To: IBM Netrexx
> Subject: Re: [Ibm-netrexx] Interesting comment behaviour
>
>
> Wouldn't this rather be the opposite - not looking at any
> syntax while in a comment?
>
> I imagine that language processors that do not suffer from
> this, have a state 'in-comment' that starts after the first
> /* and scans until the last */ - at least that is the
> definition of 'comment' that I would expect.
>
> We can also let it be and limit this to just ignore every
> line that is prefixed by -- we do not have any problem to
> 'block comment' any number of lines. (line defined as
> something that ends in at least a cr). I routinely block out
> code but fortunately I don't comment as much - only on separate lines.
>
> I would be seriously surprised if someone depended on this
> behavior - though I agree that has no relationship to the
> chance of breaking things while fixing them.
>
> A separate stage with Antlr's nested multiline comment
> algoritm would do the trick I guess, but it would be much
> more desirable to have this in the standard parser.
> This works in antlr:
>
> // ANTLR 3
> NESTED_ML_COMMENT
>     :   '/*'
>      (options {greedy=false;} : (NESTED_ML_COMMENT | .))*
>          '*/' {$channel=HIDDEN;}    ;
> .
>
> I am curious how Bill solved this in the Eclipse IDE and if
> it flags the noncompilability in the coloring to match the
> result. I'll check when I am near a real computer.
>
> best regards,
>
> René.
>
>
>
> On 2012-11-27 16:43, Rick McGuire wrote:
> > Good luck with not breaking any programs.  Implementing this would
> > require some syntax awareness within comments, but the use of
> > contractions such as "don't", etc. would seriously confuse
> the issue.
> >  
> >
> > Rick
> >
> > On Tue, Nov 27, 2012 at 10:27 AM, rvjansen
> <[hidden email]> wrote:
> >
> >> Dave,
> >>
> >> thanks for mentioning this. Somehow it strikes me as
> wrong; it also
> >> has consequences for syntax colouring applications that
> need to show
> >> that this is invalid - at least will not compile as most
> people would
> >> hope it does.
> >>
> >> I see that even -- say '/*' triggers the issue. I will be
> opening a
> >> kenai issue later and we'll see if it gathers votes; when
> it does, we
> >> might reconsider. I doubt that changing this will lead to the
> >> breakage of many existing programs - those are not compiling
> >> programs. Usage of the feature seems esoteric.
> >>
> >> best regards,
> >>
> >> René.
> >>
> >> On 2012-11-24 00:39, Dave Woodman wrote:
> >>
> >>> An interesting behaviour of block comments that bit me just
> >>> recently, posted here in the hope of sparing the others the
> >>> unexpected compile failure.
> >>>
> >>> Take the following abstracted example:-
> >>>
> >>> say "/*"
> >>>
> >>> say "OK"
> >>>
> >>> Compiles, runs, all is well
> >>>
> >>> Now comment out the first "say" with a block comment
> >>>
> >>> /*
> >>>
> >>> say "/*"
> >>>
> >>> */
> >>>
> >>> say "OK"
> >>>
> >>> Now try compiling - whoops "Error: Unmatched block comment start"
> >>>
> >>> Now, consulting the NRL reveals that this behaviour is
> implied, even
> >>> if surprising:-
> >>>
> >>> "A block comment is started by the sequence of characters
> "/*", and
> >>> is ended by the
> >>>
> >>> same sequence reversed, "*/". Within these delimiters any
> characters
> >>> are allowed
> >>>
> >>> (including quotes, which need not be paired). Block
> comments may be
> >>> nested, which
> >>>
> >>> is to say that "/*" and "*/" must pair correctly. Block
> comments may
> >>> be anywhere,
> >>>
> >>> and may be of any length. When a block comment is found, it is
> >>> treated as though it
> >>>
> >>> were a blank (which may then be removed, if adjacent to a special
> >>> character)."
> >>>
> >>> So, a quote within a comment cannot be assumed to be correct, and
> >>> nested comments are allowed, so the behaviour is correct.
> >>>
> >>> Just a small point of note,
> >>>
> >>>  Dave.
> >>>
> >>> _______________________________________________
> >>> Ibm-netrexx mailing list
> >>> [hidden email]
> >>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ [1]
> >>
> >> _______________________________________________
> >> Ibm-netrexx mailing list
> >> [hidden email]
> >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ [1]
> >
> >
> >
> > Links:
> > ------
> > [1] http://ibm-netrexx.215625.n3.nabble.com/
> >
> > _______________________________________________
> > Ibm-netrexx mailing list
> > [hidden email]
> > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Aviatrexx]

While it might be an esoteric issue that shows up only when debugging,
I've written quite a few Rexx execs that generated other Rexx execs
that included comments.

To me, this is a "know your tool" issue, no different from the RAF
that occurs when a newbie tries to append the contents of the variable
'x' to a literal string using abbuttal.

Frankly, if it weren't for the PL/I nostalgia, I'd deprecate the '/*
*/' comments, rather than change the parser.  Obviously, any working
"legacy NetRexx" program has worked around this classic behavior.

-Chip-

On 11/27/2012 11:28 rvjansen said:

>
> Wouldn't this rather be the opposite - not looking at any syntax while
> in a comment?
>
> I imagine that language processors that do not suffer from this, have
> a state 'in-comment' that starts after the first /* and scans until
> the last */ - at least that is the definition of 'comment' that I
> would expect.
>
> We can also let it be and limit this to just ignore every line that is
> prefixed by -- we do not have any problem to 'block comment' any
> number of lines. (line defined as something that ends in at least a
> cr). I routinely block out code but fortunately I don't comment as
> much - only on separate lines.
>
> I would be seriously surprised if someone depended on this behavior -
> though I agree that has no relationship to the chance of breaking
> things while fixing them.
>
> A separate stage with Antlr's nested multiline comment algoritm would
> do the trick I guess, but it would be much more desirable to have this
> in the standard parser.
> This works in antlr:
>
> // ANTLR 3
> NESTED_ML_COMMENT
>     :   '/*'
>      (options {greedy=false;} : (NESTED_ML_COMMENT | .))*
>          '*/' {$channel=HIDDEN;}    ;
> .
>
> I am curious how Bill solved this in the Eclipse IDE and if it flags
> the noncompilability in the coloring to match the result. I'll check
> when I am near a real computer.
>
> best regards,
>
> René.
>
>
>
> On 2012-11-27 16:43, Rick McGuire wrote:
>> Good luck with not breaking any programs.  Implementing this would
>> require some syntax awareness within comments, but the use of
>> contractions such as "don't", etc. would seriously confuse the issue.
>>
>>
>> Rick
>>
>> On Tue, Nov 27, 2012 at 10:27 AM, rvjansen <[hidden email]> wrote:
>>
>>> Dave,
>>>
>>> thanks for mentioning this. Somehow it strikes me as wrong; it also
>>> has consequences for syntax colouring applications that need to
>>> show that this is invalid - at least will not compile as most
>>> people would hope it does.
>>>
>>> I see that even -- say '/*' triggers the issue. I will be opening a
>>> kenai issue later and we'll see if it gathers votes; when it does,
>>> we might reconsider. I doubt that changing this will lead to the
>>> breakage of many existing programs - those are not compiling
>>> programs. Usage of the feature seems esoteric.
>>>
>>> best regards,
>>>
>>> René.
>>>
>>> On 2012-11-24 00:39, Dave Woodman wrote:
>>>
>>>> An interesting behaviour of block comments that bit me just recently,
>>>> posted here in the hope of sparing the others the unexpected compile
>>>> failure.
>>>>
>>>> Take the following abstracted example:-
>>>>
>>>> say "/*"
>>>>
>>>> say "OK"
>>>>
>>>> Compiles, runs, all is well
>>>>
>>>> Now comment out the first "say" with a block comment
>>>>
>>>> /*
>>>>
>>>> say "/*"
>>>>
>>>> */
>>>>
>>>> say "OK"
>>>>
>>>> Now try compiling - whoops "Error: Unmatched block comment start"
>>>>
>>>> Now, consulting the NRL reveals that this behaviour is implied, even
>>>> if surprising:-
>>>>
>>>> "A block comment is started by the sequence of characters "/*", and
>>>> is ended by the
>>>>
>>>> same sequence reversed, "*/". Within these delimiters any
>>>> characters are allowed
>>>>
>>>> (including quotes, which need not be paired). Block comments may be
>>>> nested, which
>>>>
>>>> is to say that "/*" and "*/" must pair correctly. Block comments may
>>>> be anywhere,
>>>>
>>>> and may be of any length. When a block comment is found, it is
>>>> treated as though it
>>>>
>>>> were a blank (which may then be removed, if adjacent to a special
>>>> character)."
>>>>
>>>> So, a quote within a comment cannot be assumed to be correct, and
>>>> nested comments are allowed, so the behaviour is correct.
>>>>
>>>> Just a small point of note,
>>>>
>>>>  Dave.
>>>>
>>>> _______________________________________________
>>>> Ibm-netrexx mailing list
>>>> [hidden email]
>>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ [1]
>>>
>>> _______________________________________________
>>> Ibm-netrexx mailing list
>>> [hidden email]
>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ [1]
>>
>>
>>
>> Links:
>> ------
>> [1] http://ibm-netrexx.215625.n3.nabble.com/
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

You would have *expected* my *objection*, I personally do think, at least:

"/*", '/*', "*/", '*/'

Have to be, therefore, defined at the *Semantic Level* (on TOP of Code
and Comments and Notes),
thus having *the Highest Precedence possible at all* ;-)

Thomas.

PS: Otherwise, *nested Comments* may fail, unfortunately! :-(

===============================================================.
Am 27.11.2012 17:53, schrieb Mike Cowlishaw:

> René,  I suspect there is some confusion/cross-purpose about what 'this
> behaviour' is.
>
> In Rexx and NetRexx, block comments (/* .... */) nest.  This allows one to
> 'comment out' a block of code of any length and complexity thus:
>
>   /* Ignore this test code
>       test code etc. /* and comments */
>       and more /* and more comments /* perhaps also with nested comments and code
> */ */
>       /* end of test code */
>   */
>
> All of which works very well in almost all cases (one can comment out stuff
> which includes commented-out stuff, and so on).
>
> The 'problem' occurs when a sequence such as
>
>    */
>
> or
>
>    /*
>
> appears in a string (or in a line comment) within a chunk of code that is being
> 'commented out'.  In these (very rare) cases the block comment will be ended
> prematurely (or a new one will be started), causing confusion.
>
> Since, by definition, a comment can contain any sequence of characters there is
> no reason to assume that the contents might be 'code' -- so there is no reason
> to interpret '*/' as though it might be code. It might be just an example within
> a comment.  As might be the sequence '/*' (with or without the quotes).
>
> In short .. inside comments, comment rules apply, not code rules.  Applying code
> rules within comments will most surely break many programs.  In contrast the
> comment rules are clean and simple, and in the rare cases when there is an
> embedded /* or */ this is rapidly discovered.
>
> Of course, a compiler could give a helpful warning ("this looks as though you
> might have an embedded string literal that ends the comment") .. but that's very
> different from changing the parsing rules.
>
> Mike
>
>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of rvjansen
>> Sent: 27 November 2012 16:29
>> To: IBM Netrexx
>> Subject: Re: [Ibm-netrexx] Interesting comment behaviour
>>
>>
>> Wouldn't this rather be the opposite - not looking at any
>> syntax while in a comment?
>>
>> I imagine that language processors that do not suffer from
>> this, have a state 'in-comment' that starts after the first
>> /* and scans until the last */ - at least that is the
>> definition of 'comment' that I would expect.
>>
>> We can also let it be and limit this to just ignore every
>> line that is prefixed by -- we do not have any problem to
>> 'block comment' any number of lines. (line defined as
>> something that ends in at least a cr). I routinely block out
>> code but fortunately I don't comment as much - only on separate lines.
>>
>> I would be seriously surprised if someone depended on this
>> behavior - though I agree that has no relationship to the
>> chance of breaking things while fixing them.
>>
>> A separate stage with Antlr's nested multiline comment
>> algoritm would do the trick I guess, but it would be much
>> more desirable to have this in the standard parser.
>> This works in antlr:
>>
>> // ANTLR 3
>> NESTED_ML_COMMENT
>>      :   '/*'
>>       (options {greedy=false;} : (NESTED_ML_COMMENT | .))*
>>           '*/' {$channel=HIDDEN;}    ;
>> .
>>
>> I am curious how Bill solved this in the Eclipse IDE and if
>> it flags the noncompilability in the coloring to match the
>> result. I'll check when I am near a real computer.
>>
>> best regards,
>>
>> René.
>>
>>
>>
>> On 2012-11-27 16:43, Rick McGuire wrote:
>>> Good luck with not breaking any programs.  Implementing this would
>>> require some syntax awareness within comments, but the use of
>>> contractions such as "don't", etc. would seriously confuse
>> the issue.
>>>  
>>>
>>> Rick
>>>
>>> On Tue, Nov 27, 2012 at 10:27 AM, rvjansen
>> <[hidden email]> wrote:
>>>> Dave,
>>>>
>>>> thanks for mentioning this. Somehow it strikes me as
>> wrong; it also
>>>> has consequences for syntax colouring applications that
>> need to show
>>>> that this is invalid - at least will not compile as most
>> people would
>>>> hope it does.
>>>>
>>>> I see that even -- say '/*' triggers the issue. I will be
>> opening a
>>>> kenai issue later and we'll see if it gathers votes; when
>> it does, we
>>>> might reconsider. I doubt that changing this will lead to the
>>>> breakage of many existing programs - those are not compiling
>>>> programs. Usage of the feature seems esoteric.
>>>>
>>>> best regards,
>>>>
>>>> René.
>>>>
>>>> On 2012-11-24 00:39, Dave Woodman wrote:
>>>>
>>>>> An interesting behaviour of block comments that bit me just
>>>>> recently, posted here in the hope of sparing the others the
>>>>> unexpected compile failure.
>>>>>
>>>>> Take the following abstracted example:-
>>>>>
>>>>> say "/*"
>>>>>
>>>>> say "OK"
>>>>>
>>>>> Compiles, runs, all is well
>>>>>
>>>>> Now comment out the first "say" with a block comment
>>>>>
>>>>> /*
>>>>>
>>>>> say "/*"
>>>>>
>>>>> */
>>>>>
>>>>> say "OK"
>>>>>
>>>>> Now try compiling - whoops "Error: Unmatched block comment start"
>>>>>
>>>>> Now, consulting the NRL reveals that this behaviour is
>> implied, even
>>>>> if surprising:-
>>>>>
>>>>> "A block comment is started by the sequence of characters
>> "/*", and
>>>>> is ended by the
>>>>>
>>>>> same sequence reversed, "*/". Within these delimiters any
>> characters
>>>>> are allowed
>>>>>
>>>>> (including quotes, which need not be paired). Block
>> comments may be
>>>>> nested, which
>>>>>
>>>>> is to say that "/*" and "*/" must pair correctly. Block
>> comments may
>>>>> be anywhere,
>>>>>
>>>>> and may be of any length. When a block comment is found, it is
>>>>> treated as though it
>>>>>
>>>>> were a blank (which may then be removed, if adjacent to a special
>>>>> character)."
>>>>>
>>>>> So, a quote within a comment cannot be assumed to be correct, and
>>>>> nested comments are allowed, so the behaviour is correct.
>>>>>
>>>>> Just a small point of note,
>>>>>
>>>>>   Dave.
>>>>>
>>>>> _______________________________________________
>>>>> Ibm-netrexx mailing list
>>>>> [hidden email]
>>>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ [1]
>>>> _______________________________________________
>>>> Ibm-netrexx mailing list
>>>> [hidden email]
>>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ [1]
>>>
>>>
>>> Links:
>>> ------
>>> [1] http://ibm-netrexx.215625.n3.nabble.com/
>>>
>>> _______________________________________________
>>> Ibm-netrexx mailing list
>>> [hidden email]
>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>
>>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>

--
http://www.thsitc.com Austria, Europe Skype ID: Thomas.Schneider.Wien
Yahoo ID: [hidden email] FaceBook ID: Thomas.Schneider.Wien Member
of the Rexx Languge Asscociation (www.rexxla.org) Member of the NetRexx
Developer's Team (www.netrexx.org)

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Dave Woodman]

Hi René,

I too think that changing this may well be more hassle than it is worth - but perhaps it should be explicitly documented (as it is, it is implied behaviour).

As an aside to your Eclipse aside, jEdit behaves correctly when it comes to recognising this syntax, although it does not work with a javadoc style comment - i.e. it shows the following to be correct when it is not

        /** javadoc style comment

        '/*' quoted comment

        */  -- close comment - one missing!!!

        <rest of source unseen by translator>

An edge condition, I agree!

        Cheers,

                Dave.


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of rvjansen
Sent: 27 November 2012 16:29
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] Interesting comment behaviour

       
Wouldn't this rather be the opposite - not looking at any syntax while in a comment?

I imagine that language processors that do not suffer from this, have a state 'in-comment' that starts after the first /* and scans until the last */ - at least that is the definition of 'comment' that I would expect.

We can also let it be and limit this to just ignore every line that is prefixed by -- we do not have any problem to 'block comment' any number of lines. (line defined as something that ends in at least a cr). I routinely block out code but fortunately I don't comment as much - only on separate lines.

I would be seriously surprised if someone depended on this behavior - though I agree that has no relationship to the chance of breaking things while fixing them.

A separate stage with Antlr's nested multiline comment algoritm would do the trick I guess, but it would be much more desirable to have this in the standard parser.
This works in antlr:

// ANTLR 3
NESTED_ML_COMMENT
    :   '/*'
     (options {greedy=false;} : (NESTED_ML_COMMENT | .))*
         '*/' {$channel=HIDDEN;}    ;
.

I am curious how Bill solved this in the Eclipse IDE and if it flags the noncompilability in the coloring to match the result. I'll check when I am near a real computer.

best regards,

René.



On 2012-11-27 16:43, Rick McGuire wrote:

> Good luck with not breaking any programs.  Implementing this would
> require some syntax awareness within comments, but the use of
> contractions such as "don't", etc. would seriously confuse the issue.
>  
>
> Rick
>
> On Tue, Nov 27, 2012 at 10:27 AM, rvjansen <[hidden email]> wrote:
>
>> Dave,
>>
>> thanks for mentioning this. Somehow it strikes me as wrong; it also
>> has consequences for syntax colouring applications that need to show
>> that this is invalid - at least will not compile as most people would
>> hope it does.
>>
>> I see that even -- say '/*' triggers the issue. I will be opening a
>> kenai issue later and we'll see if it gathers votes; when it does, we
>> might reconsider. I doubt that changing this will lead to the
>> breakage of many existing programs - those are not compiling
>> programs. Usage of the feature seems esoteric.
>>
>> best regards,
>>
>> René.
>>
>> On 2012-11-24 00:39, Dave Woodman wrote:
>>
>>> An interesting behaviour of block comments that bit me just
>>> recently, posted here in the hope of sparing the others the
>>> unexpected compile failure.
>>>
>>> Take the following abstracted example:-
>>>
>>> say "/*"
>>>
>>> say "OK"
>>>
>>> Compiles, runs, all is well
>>>
>>> Now comment out the first "say" with a block comment
>>>
>>> /*
>>>
>>> say "/*"
>>>
>>> */
>>>
>>> say "OK"
>>>
>>> Now try compiling - whoops "Error: Unmatched block comment start"
>>>
>>> Now, consulting the NRL reveals that this behaviour is implied, even
>>> if surprising:-
>>>
>>> "A block comment is started by the sequence of characters "/*", and
>>> is ended by the
>>>
>>> same sequence reversed, "*/". Within these delimiters any characters
>>> are allowed
>>>
>>> (including quotes, which need not be paired). Block comments may be
>>> nested, which
>>>
>>> is to say that "/*" and "*/" must pair correctly. Block comments may
>>> be anywhere,
>>>
>>> and may be of any length. When a block comment is found, it is
>>> treated as though it
>>>
>>> were a blank (which may then be removed, if adjacent to a special
>>> character)."
>>>
>>> So, a quote within a comment cannot be assumed to be correct, and
>>> nested comments are allowed, so the behaviour is correct.
>>>
>>> Just a small point of note,
>>>
>>>  Dave.
>>>
>>> _______________________________________________
>>> Ibm-netrexx mailing list
>>> [hidden email]
>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ [1]
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ [1]
>
>
>
> Links:
> ------
> [1] http://ibm-netrexx.215625.n3.nabble.com/
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

What *I* did try, for experimantations only, is requiring:

/**   -- as a JOVA DOC Comment
   [*]
   ...
   */

/***--   -- as a BLOCK OUT (nested comment)

--***/

Thus saying two things:

"/***--*  -- does COMMENT OUT a piece of code.

"--***/  -- does finish it ...

Has been just fro trials, of course, as it's not defined in the NetRexx
Language!

We *shall*, however, ADOPT JAVA DOC Domments as a *feature* in NetRexx,
ASAP, Please!

SYNERGY is better than *Distractions*, I'm still feeling, at least!
Thomas.
========================================================

Am 27.11.2012 17:28, schrieb rvjansen:

>
> Wouldn't this rather be the opposite - not looking at any syntax while
> in a comment?
>
> I imagine that language processors that do not suffer from this, have
> a state 'in-comment' that starts after the first /* and scans until
> the last */ - at least that is the definition of 'comment' that I
> would expect.
>
> We can also let it be and limit this to just ignore every line that is
> prefixed by -- we do not have any problem to 'block comment' any
> number of lines. (line defined as something that ends in at least a
> cr). I routinely block out code but fortunately I don't comment as
> much - only on separate lines.
>
> I would be seriously surprised if someone depended on this behavior -
> though I agree that has no relationship to the chance of breaking
> things while fixing them.
>
> A separate stage with Antlr's nested multiline comment algoritm would
> do the trick I guess, but it would be much more desirable to have this
> in the standard parser.
> This works in antlr:
>
> // ANTLR 3
> NESTED_ML_COMMENT
>    :   '/*'
>     (options {greedy=false;} : (NESTED_ML_COMMENT | .))*
>         '*/' {$channel=HIDDEN;}    ;
> .
>
> I am curious how Bill solved this in the Eclipse IDE and if it flags
> the noncompilability in the coloring to match the result. I'll check
> when I am near a real computer.
>
> best regards,
>
> René.
>
>
>
> On 2012-11-27 16:43, Rick McGuire wrote:
>> Good luck with not breaking any programs.  Implementing this would
>> require some syntax awareness within comments, but the use of
>> contractions such as "don't", etc. would seriously confuse the issue.
>>
>>
>> Rick
>>
>> On Tue, Nov 27, 2012 at 10:27 AM, rvjansen <[hidden email]> wrote:
>>
>>> Dave,
>>>
>>> thanks for mentioning this. Somehow it strikes me as wrong; it also
>>> has consequences for syntax colouring applications that need to show
>>> that this is invalid - at least will not compile as most people
>>> would hope it does.
>>>
>>> I see that even -- say '/*' triggers the issue. I will be opening a
>>> kenai issue later and we'll see if it gathers votes; when it does,
>>> we might reconsider. I doubt that changing this will lead to the
>>> breakage of many existing programs - those are not compiling
>>> programs. Usage of the feature seems esoteric.
>>>
>>> best regards,
>>>
>>> René.
>>>
>>> On 2012-11-24 00:39, Dave Woodman wrote:
>>>
>>>> An interesting behaviour of block comments that bit me just recently,
>>>> posted here in the hope of sparing the others the unexpected compile
>>>> failure.
>>>>
>>>> Take the following abstracted example:-
>>>>
>>>> say "/*"
>>>>
>>>> say "OK"
>>>>
>>>> Compiles, runs, all is well
>>>>
>>>> Now comment out the first "say" with a block comment
>>>>
>>>> /*
>>>>
>>>> say "/*"
>>>>
>>>> */
>>>>
>>>> say "OK"
>>>>
>>>> Now try compiling - whoops "Error: Unmatched block comment start"
>>>>
>>>> Now, consulting the NRL reveals that this behaviour is implied, even
>>>> if surprising:-
>>>>
>>>> "A block comment is started by the sequence of characters "/*", and
>>>> is ended by the
>>>>
>>>> same sequence reversed, "*/". Within these delimiters any
>>>> characters are allowed
>>>>
>>>> (including quotes, which need not be paired). Block comments may be
>>>> nested, which
>>>>
>>>> is to say that "/*" and "*/" must pair correctly. Block comments may
>>>> be anywhere,
>>>>
>>>> and may be of any length. When a block comment is found, it is
>>>> treated as though it
>>>>
>>>> were a blank (which may then be removed, if adjacent to a special
>>>> character)."
>>>>
>>>> So, a quote within a comment cannot be assumed to be correct, and
>>>> nested comments are allowed, so the behaviour is correct.
>>>>
>>>> Just a small point of note,
>>>>
>>>>  Dave.
>>>>
>>>> _______________________________________________
>>>> Ibm-netrexx mailing list
>>>> [hidden email]
>>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ [1]
>>>
>>> _______________________________________________
>>> Ibm-netrexx mailing list
>>> [hidden email]
>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ [1]
>>
>>
>>
>> Links:
>> ------
>> [1] http://ibm-netrexx.215625.n3.nabble.com/
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>

--
http://www.thsitc.com Austria, Europe Skype ID: Thomas.Schneider.Wien
Yahoo ID: [hidden email] FaceBook ID: Thomas.Schneider.Wien Member
of the Rexx Languge Asscociation (www.rexxla.org) Member of the NetRexx
Developer's Team (www.netrexx.org)

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[billfen]

Rene,

The approach used by the Eclipse plugin is to recognize comment nesting
during tokenization, and to recognize missing or extraneous delimiters
during parsing.  In many cases a quoted delimiter is correctly
recognized, but not always.  Because a comment may contain any
characters, checks for quoted strings within comments do not work well.

The colorization allows nested comments to be colored differently from
non nested comments.  If a mismatch occurs, an error message is
displayed.  In general, errors caused by quoted delimiters are not much
of a problem because of the colorization and error message.

In an earlier note on this thread I said something like:

     To be bullet proof, "say '/' || '*' " should be used.

     A useful footnote in the language reference might be something like
"Quoted string literals containing the sequences '/*' or '*/' should be
avoided."

I first ran into this problem with my original Rexx parser for Lexx in
the 1980's..

Bill

On 11/27/2012 11:28 AM, rvjansen wrote:

>
> I am curious how Bill solved this in the Eclipse IDE and if it flags
> the noncompilability in the coloring to match the result. I'll check
> when I am near a real computer.
>
> best regards,
>
> René.
>
>
>
> On 2012-11-27 16:43, Rick McGuire wrote:
>> Good luck with not breaking any programs.  Implementing this would
>> require some syntax awareness within comments, but the use of
>> contractions such as "don't", etc. would seriously confuse the issue.
>>
>>
>> Rick
>>
>> On Tue, Nov 27, 2012 at 10:27 AM, rvjansen <[hidden email]> wrote:
>>
>>> Dave,
>>>
>>> thanks for mentioning this. Somehow it strikes me as wrong; it also
>>> has consequences for syntax colouring applications that need to show
>>> that this is invalid - at least will not compile as most people
>>> would hope it does.
>>>
>>> I see that even -- say '/*' triggers the issue. I will be opening a
>>> kenai issue later and we'll see if it gathers votes; when it does,
>>> we might reconsider. I doubt that changing this will lead to the
>>> breakage of many existing programs - those are not compiling
>>> programs. Usage of the feature seems esoteric.
>>>
>>> best regards,
>>>
>>> René.
>>>
>>> On 2012-11-24 00:39, Dave Woodman wrote:
>>>
>>>> An interesting behaviour of block comments that bit me just recently,
>>>> posted here in the hope of sparing the others the unexpected compile
>>>> failure.
>>>>
>>>> Take the following abstracted example:-
>>>>
>>>> say "/*"
>>>>
>>>> say "OK"
>>>>
>>>> Compiles, runs, all is well
>>>>
>>>> Now comment out the first "say" with a block comment
>>>>
>>>> /*
>>>>
>>>> say "/*"
>>>>
>>>> */
>>>>
>>>> say "OK"
>>>>
>>>> Now try compiling - whoops "Error: Unmatched block comment start"
>>>>
>>>> Now, consulting the NRL reveals that this behaviour is implied, even
>>>> if surprising:-
>>>>
>>>> "A block comment is started by the sequence of characters "/*", and
>>>> is ended by the
>>>>
>>>> same sequence reversed, "*/". Within these delimiters any
>>>> characters are allowed
>>>>
>>>> (including quotes, which need not be paired). Block comments may be
>>>> nested, which
>>>>
>>>> is to say that "/*" and "*/" must pair correctly. Block comments may
>>>> be anywhere,
>>>>
>>>> and may be of any length. When a block comment is found, it is
>>>> treated as though it
>>>>
>>>> were a blank (which may then be removed, if adjacent to a special
>>>> character)."
>>>>
>>>> So, a quote within a comment cannot be assumed to be correct, and
>>>> nested comments are allowed, so the behaviour is correct.
>>>>
>>>> Just a small point of note,
>>>>
>>>>  Dave.
>>>>
>>>> _______________________________________________
>>>> Ibm-netrexx mailing list
>>>> [hidden email]
>>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ [1]
>>>
>>> _______________________________________________
>>> Ibm-netrexx mailing list
>>> [hidden email]
>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ [1]
>>
>>
>>
>> Links:
>> ------
>> [1] http://ibm-netrexx.215625.n3.nabble.com/
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.2793 / Virus Database: 2629/5893 - Release Date: 11/13/12
> Internal Virus Database is out of date.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Mike Cowlishaw]

 
> Frankly, if it weren't for the PL/I nostalgia, I'd deprecate
> the '/* */' comments, rather than change the parser.  

"Where I'm at" on this is:

a) Use block comments for 'interfaces and contracts' -- commentary about the
code that is important to someone else using it.

b) Use line comments for all else -- discussion on implementation strategies,
local explanation of code, etc.

[I've codified that for C programs I write and pretty much do the same for Rexx
programs.  See http://speleotrove.com/tollos/code_conventions.html for the
former.]

...

So maybe there's a need for a third 'comment out' syntax?

Perhaps ..

 #if expr
   ..
   ..
 #endif

?

<ducks>
 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

Hi Chip, sorry to *disagree*, again:

- *When* "/*" ...and... "*/" *are defined as *Start of Comment ... End
of Comment*

     *and*

    Nested Comments *are* allowed,

- *Then*

     - Any Occurences of "/*", "*/", as well as '/*...' and '... */'
*have to be *treated as special cases!

The Definition of SOC ::== Start of comment, EOC ::= End of Comment, is
*simply* one SEMANTIC LEVEL Higher, in the Language given, as anything
else, *when* *Nested Comments* are permitted and supported!!

Full Stop ;-)

Thomas.
====================================================================================
Am 27.11.2012 18:06, schrieb Chip Davis:

> While it might be an esoteric issue that shows up only when debugging,
> I've written quite a few Rexx execs that generated other Rexx execs
> that included comments.
>
> To me, this is a "know your tool" issue, no different from the RAF
> that occurs when a newbie tries to append the contents of the variable
> 'x' to a literal string using abbuttal.
>
> Frankly, if it weren't for the PL/I nostalgia, I'd deprecate the '/*
> */' comments, rather than change the parser.  Obviously, any working
> "legacy NetRexx" program has worked around this classic behavior.
>
> -Chip-
>
> On 11/27/2012 11:28 rvjansen said:
>>
>> Wouldn't this rather be the opposite - not looking at any syntax while
>> in a comment?
>>
>> I imagine that language processors that do not suffer from this, have
>> a state 'in-comment' that starts after the first /* and scans until
>> the last */ - at least that is the definition of 'comment' that I
>> would expect.
>>
>> We can also let it be and limit this to just ignore every line that is
>> prefixed by -- we do not have any problem to 'block comment' any
>> number of lines. (line defined as something that ends in at least a
>> cr). I routinely block out code but fortunately I don't comment as
>> much - only on separate lines.
>>
>> I would be seriously surprised if someone depended on this behavior -
>> though I agree that has no relationship to the chance of breaking
>> things while fixing them.
>>
>> A separate stage with Antlr's nested multiline comment algoritm would
>> do the trick I guess, but it would be much more desirable to have this
>> in the standard parser.
>> This works in antlr:
>>
>> // ANTLR 3
>> NESTED_ML_COMMENT
>>     :   '/*'
>>      (options {greedy=false;} : (NESTED_ML_COMMENT | .))*
>>          '*/' {$channel=HIDDEN;}    ;
>> .
>>
>> I am curious how Bill solved this in the Eclipse IDE and if it flags
>> the noncompilability in the coloring to match the result. I'll check
>> when I am near a real computer.
>>
>> best regards,
>>
>> René.
>>
>>
>>
>> On 2012-11-27 16:43, Rick McGuire wrote:
>>> Good luck with not breaking any programs.  Implementing this would
>>> require some syntax awareness within comments, but the use of
>>> contractions such as "don't", etc. would seriously confuse the issue.
>>>
>>>
>>> Rick
>>>
>>> On Tue, Nov 27, 2012 at 10:27 AM, rvjansen <[hidden email]> wrote:
>>>
>>>> Dave,
>>>>
>>>> thanks for mentioning this. Somehow it strikes me as wrong; it also
>>>> has consequences for syntax colouring applications that need to
>>>> show that this is invalid - at least will not compile as most
>>>> people would hope it does.
>>>>
>>>> I see that even -- say '/*' triggers the issue. I will be opening a
>>>> kenai issue later and we'll see if it gathers votes; when it does,
>>>> we might reconsider. I doubt that changing this will lead to the
>>>> breakage of many existing programs - those are not compiling
>>>> programs. Usage of the feature seems esoteric.
>>>>
>>>> best regards,
>>>>
>>>> René.
>>>>
>>>> On 2012-11-24 00:39, Dave Woodman wrote:
>>>>
>>>>> An interesting behaviour of block comments that bit me just recently,
>>>>> posted here in the hope of sparing the others the unexpected compile
>>>>> failure.
>>>>>
>>>>> Take the following abstracted example:-
>>>>>
>>>>> say "/*"
>>>>>
>>>>> say "OK"
>>>>>
>>>>> Compiles, runs, all is well
>>>>>
>>>>> Now comment out the first "say" with a block comment
>>>>>
>>>>> /*
>>>>>
>>>>> say "/*"
>>>>>
>>>>> */
>>>>>
>>>>> say "OK"
>>>>>
>>>>> Now try compiling - whoops "Error: Unmatched block comment start"
>>>>>
>>>>> Now, consulting the NRL reveals that this behaviour is implied, even
>>>>> if surprising:-
>>>>>
>>>>> "A block comment is started by the sequence of characters "/*", and
>>>>> is ended by the
>>>>>
>>>>> same sequence reversed, "*/". Within these delimiters any
>>>>> characters are allowed
>>>>>
>>>>> (including quotes, which need not be paired). Block comments may be
>>>>> nested, which
>>>>>
>>>>> is to say that "/*" and "*/" must pair correctly. Block comments may
>>>>> be anywhere,
>>>>>
>>>>> and may be of any length. When a block comment is found, it is
>>>>> treated as though it
>>>>>
>>>>> were a blank (which may then be removed, if adjacent to a special
>>>>> character)."
>>>>>
>>>>> So, a quote within a comment cannot be assumed to be correct, and
>>>>> nested comments are allowed, so the behaviour is correct.
>>>>>
>>>>> Just a small point of note,
>>>>>
>>>>>  Dave.
>>>>>
>>>>> _______________________________________________
>>>>> Ibm-netrexx mailing list
>>>>> [hidden email]
>>>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ [1]
>>>>
>>>> _______________________________________________
>>>> Ibm-netrexx mailing list
>>>> [hidden email]
>>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ [1]
>>>
>>>
>>>
>>> Links:
>>> ------
>>> [1] http://ibm-netrexx.215625.n3.nabble.com/
>>>
>>> _______________________________________________
>>> Ibm-netrexx mailing list
>>> [hidden email]
>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>

--
http://www.thsitc.com Austria, Europe Skype ID: Thomas.Schneider.Wien
Yahoo ID: [hidden email] FaceBook ID: Thomas.Schneider.Wien Member
of the Rexx Languge Asscociation (www.rexxla.org) Member of the NetRexx
Developer's Team (www.netrexx.org)

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Aviatrexx]

Shhh!  Thomas might hear you...

On 11/27/2012 12:44 Mike Cowlishaw said:

> So maybe there's a need for a third 'comment out' syntax?
>
> Perhaps ..
>
>   #if expr
>     ..
>     ..
>   #endif
>
> ?
>
> <ducks>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

*HI*, Chip, Mike, ...

I'm *listening* any *and all* *opinions*, *Behaviours*, *Good Ideas*,
*Bad Ideas*, etc etc...

*I* am simply a *Living ROBOT*!  (At Least, my computers are ...)

Anything, and everything, having to do with the *SEMANTICS* of any
*Language*
has to be defined *precisely*, *on the SEMANTIC *as well* as the
SYNTACTIC* Level.

SEMANTICS of  *Languages* ...

... *cannot be defined* by *Syntax Diagrams* ...

(at least, I'm thinking so ...; I might be wrong, of course! ... *who
not* ???)

Thomas.
==============================================================
Am 27.11.2012 18:56, schrieb Chip Davis:

> Shhh! Thomas might hear you...
>
> On 11/27/2012 12:44 Mike Cowlishaw said:
>> So maybe there's a need for a third 'comment out' syntax?
>>
>> Perhaps ..
>>
>>   #if expr
>>     ..
>>     ..
>>   #endif
>>
>> ?
>>
>> <ducks>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>

--
http://www.thsitc.com Austria, Europe Skype ID: Thomas.Schneider.Wien
Yahoo ID: [hidden email] FaceBook ID: Thomas.Schneider.Wien Member
of the Rexx Languge Asscociation (www.rexxla.org) Member of the NetRexx
Developer's Team (www.netrexx.org)

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

++++1:

Mike!

*Excellent*,
*Brilliant*,

as *nearly everything* having beeing done from your shop!

Anyway:

Kermit *is* right:

*When* the Family of Rexx Languages, Dialects, etc, *including NetRexx*,
*ooRexx*, *Regina*,
etc will *diverge* with any release (as they currently do, sorry to say,
...)

*Then*

NetRexx, ooRexx, Regina, classic Rexx, etc

*********************************************
* WILL Die (together, as *any Family*
*
* ***not***
* working *together* (as Turkish Families, for instance, nowadays do ... :-)
*********************************************

Comprendi?
  (Italiano, by the way) ...

The *Rexx Family of Languages* does *not* co-work!

Each member of this *Family* has hes/her preferences ...

Thus:

FIGHTs fo occur, as between KAIN and ABEL!

So what:

*who wants to be KAIN, there, at RexxLA, and/or Ibm-NetRexx*,
*and* wants to be ABEL ???

Are *we all* becoming more stupid, by years, of what!

Any *reason* to repeat this *totally needless Game*: ??

*Who is Stronger*:

You, or me, or what ?
?????????????????????????????????
=========================================================





Am 27.11.2012 18:44, schrieb Mike Cowlishaw:

>  
>> Frankly, if it weren't for the PL/I nostalgia, I'd deprecate
>> the '/* */' comments, rather than change the parser.
> "Where I'm at" on this is:
>
> a) Use block comments for 'interfaces and contracts' -- commentary about the
> code that is important to someone else using it.
>
> b) Use line comments for all else -- discussion on implementation strategies,
> local explanation of code, etc.
>
> [I've codified that for C programs I write and pretty much do the same for Rexx
> programs.  See http://speleotrove.com/tollos/code_conventions.html for the
> former.]
>
> ...
>
> So maybe there's a need for a third 'comment out' syntax?
>
> Perhaps ..
>
>   #if expr
>     ..
>     ..
>   #endif
>
> ?
>
> <ducks>
>  
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>

--
http://www.thsitc.com Austria, Europe Skype ID: Thomas.Schneider.Wien
Yahoo ID: [hidden email] FaceBook ID: Thomas.Schneider.Wien Member
of the Rexx Languge Asscociation (www.rexxla.org) Member of the NetRexx
Developer's Team (www.netrexx.org)

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[rvjansen]

Bill,

interesting, and I would suggest to the Project Editor to include the suggested sentence.

I am not entirely happy with what I learned today. C has no nested comments; but I honestly expected from Rexx that something like

#!/usr/bin/env ruby

=begin
Between =begin and =end, any number
of lines may be written. All of these
lines are ignored by the Ruby interpreter;
even the ones with '=' or '#' '/*' in them.
=end

puts "Hello world!"

would just work. Yes, and I know where to find it if I really want it.
I also agree with Dave that it is a corner case, and with Rick that we would probably need to leave it, certainly when you state that it was there from the beginning.

If we ever do a 'document here' style of continuation-less string entry, we might have a comment variant of it for free.

best regards,

René.

On 27 nov. 2012, at 18:37, Bill Fenlason <[hidden email]> wrote:

> Rene,
>
> The approach used by the Eclipse plugin is to recognize comment nesting during tokenization, and to recognize missing or extraneous delimiters during parsing.  In many cases a quoted delimiter is correctly recognized, but not always.  Because a comment may contain any characters, checks for quoted strings within comments do not work well.
>
> The colorization allows nested comments to be colored differently from non nested comments.  If a mismatch occurs, an error message is displayed.  In general, errors caused by quoted delimiters are not much of a problem because of the colorization and error message.
>
> In an earlier note on this thread I said something like:
>
>    To be bullet proof, "say '/' || '*' " should be used.
>
>    A useful footnote in the language reference might be something like "Quoted string literals containing the sequences '/*' or '*/' should be avoided."
>
> I first ran into this problem with my original Rexx parser for Lexx in the 1980's..
>
> Bill
>
> On 11/27/2012 11:28 AM, rvjansen wrote:
>>
>> I am curious how Bill solved this in the Eclipse IDE and if it flags the noncompilability in the coloring to match the result. I'll check when I am near a real computer.
>>
>> best regards,
>>
>> René.
>>
>>
>>
>> On 2012-11-27 16:43, Rick McGuire wrote:
>>> Good luck with not breaking any programs.  Implementing this would
>>> require some syntax awareness within comments, but the use of
>>> contractions such as "don't", etc. would seriously confuse the issue.
>>>
>>>
>>> Rick
>>>
>>> On Tue, Nov 27, 2012 at 10:27 AM, rvjansen <[hidden email]> wrote:
>>>
>>>> Dave,
>>>>
>>>> thanks for mentioning this. Somehow it strikes me as wrong; it also has consequences for syntax colouring applications that need to show that this is invalid - at least will not compile as most people would hope it does.
>>>>
>>>> I see that even -- say '/*' triggers the issue. I will be opening a kenai issue later and we'll see if it gathers votes; when it does, we might reconsider. I doubt that changing this will lead to the breakage of many existing programs - those are not compiling programs. Usage of the feature seems esoteric.
>>>>
>>>> best regards,
>>>>
>>>> René.
>>>>
>>>> On 2012-11-24 00:39, Dave Woodman wrote:
>>>>
>>>>> An interesting behaviour of block comments that bit me just recently,
>>>>> posted here in the hope of sparing the others the unexpected compile
>>>>> failure.
>>>>>
>>>>> Take the following abstracted example:-
>>>>>
>>>>> say "/*"
>>>>>
>>>>> say "OK"
>>>>>
>>>>> Compiles, runs, all is well
>>>>>
>>>>> Now comment out the first "say" with a block comment
>>>>>
>>>>> /*
>>>>>
>>>>> say "/*"
>>>>>
>>>>> */
>>>>>
>>>>> say "OK"
>>>>>
>>>>> Now try compiling - whoops "Error: Unmatched block comment start"
>>>>>
>>>>> Now, consulting the NRL reveals that this behaviour is implied, even
>>>>> if surprising:-
>>>>>
>>>>> "A block comment is started by the sequence of characters "/*", and
>>>>> is ended by the
>>>>>
>>>>> same sequence reversed, "*/". Within these delimiters any characters are allowed
>>>>>
>>>>> (including quotes, which need not be paired). Block comments may be
>>>>> nested, which
>>>>>
>>>>> is to say that "/*" and "*/" must pair correctly. Block comments may
>>>>> be anywhere,
>>>>>
>>>>> and may be of any length. When a block comment is found, it is
>>>>> treated as though it
>>>>>
>>>>> were a blank (which may then be removed, if adjacent to a special character)."
>>>>>
>>>>> So, a quote within a comment cannot be assumed to be correct, and
>>>>> nested comments are allowed, so the behaviour is correct.
>>>>>
>>>>> Just a small point of note,
>>>>>
>>>>> Dave.
>>>>>
>>>>> _______________________________________________
>>>>> Ibm-netrexx mailing list
>>>>> [hidden email]
>>>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ [1]
>>>>
>>>> _______________________________________________
>>>> Ibm-netrexx mailing list
>>>> [hidden email]
>>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ [1]
>>>
>>>
>>>
>>> Links:
>>> ------
>>> [1] http://ibm-netrexx.215625.n3.nabble.com/
>>>
>>> _______________________________________________
>>> Ibm-netrexx mailing list
>>> [hidden email]
>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2013.0.2793 / Virus Database: 2629/5893 - Release Date: 11/13/12
>> Internal Virus Database is out of date.
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Rony G. Flatscher (wu-wien)]

On 28.11.2012 00:14, René Jansen wrote:

> interesting, and I would suggest to the Project Editor to include the suggested sentence.
>
> I am not entirely happy with what I learned today. C has no nested comments; but I honestly expected from Rexx that something like
>
> #!/usr/bin/env ruby
>
> =begin
> Between =begin and =end, any number
> of lines may be written. All of these
> lines are ignored by the Ruby interpreter;
> even the ones with '=' or '#' '/*' in them.
> =end
>
> puts "Hello world!"
>
> would just work. Yes, and I know where to find it if I really want it.
> I also agree with Dave that it is a corner case, and with Rick that we would probably need to leave it, certainly when you state that it was there from the beginning.
>
> If we ever do a 'document here' style of continuation-less string entry, we might have a comment variant of it for free.

Maybe a "Rexx neutral" example of cases, where a sequence of characters may yield unexpected
results, if one is not aware of the semantics of the concept in hand: in SGML/XML there are CDATA
sections (cf. <http://www.w3.org/TR/2008/REC-xml-20081126/#sec-cdata-sect>) which are led in by the
character sequence (without the quotes that stress the character sequence) "<![CDATA[" with any
character sequence in between and led out (ended) by the sequence "]]>".

CDATA sections are used among other things to allow programming code to be embedded verbatimly in
marked up text adhering to SGML/XML rules. Otherwise the characters <, >, & which are usually used
in code need to be changed to &lt;, &gt; and &amp; which seems to be quite cumbersome.

Here, from time to time a problem occurs, if the code (in any language) was defining a literal in
the form of "]]>", which will end the CDATA section. For those, who are not aware of what a CDATA
section consitutes, the surprise factor is high. However, it is only high, because the coders might
not have full information about CDATA sections. Such cases occur if code embedded in CDATA sections
is there to create programmatically CDATA sections as well.

Block comments are the same: once opened everything is ignored unless the character sequences /* or
*/ are encountered. Which is actually a very simple rule. A programmer who is not aware of the
definition of a comment might be surprised. But, hey, there is always something new to be learned
everyday! ;)

---rony

P.S.: And independently of PL/I, nestable block comments are great from time to time as they easily
allow to comment out sections of code.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

+++1!

So Many Thanks, Roni, *for your CLARIFICATION*, and Link, as well!

So what is the Difference between the SEMANTIC *and* The SYNTAX, of any
and all  languages,
now ???

Puzzle Number *oo* for all of you, OK ???
Thomas.
=========================================================
Am 28.11.2012 11:06, schrieb Rony G. Flatscher:

> On 28.11.2012 00:14, René Jansen wrote:
>> interesting, and I would suggest to the Project Editor to include the suggested sentence.
>>
>> I am not entirely happy with what I learned today. C has no nested comments; but I honestly expected from Rexx that something like
>>
>> #!/usr/bin/env ruby
>>
>> =begin
>> Between =begin and =end, any number
>> of lines may be written. All of these
>> lines are ignored by the Ruby interpreter;
>> even the ones with '=' or '#' '/*' in them.
>> =end
>>
>> puts "Hello world!"
>>
>> would just work. Yes, and I know where to find it if I really want it.
>> I also agree with Dave that it is a corner case, and with Rick that we would probably need to leave it, certainly when you state that it was there from the beginning.
>>
>> If we ever do a 'document here' style of continuation-less string entry, we might have a comment variant of it for free.
> Maybe a "Rexx neutral" example of cases, where a sequence of characters may yield unexpected
> results, if one is not aware of the semantics of the concept in hand: in SGML/XML there are CDATA
> sections (cf. <http://www.w3.org/TR/2008/REC-xml-20081126/#sec-cdata-sect>) which are led in by the
> character sequence (without the quotes that stress the character sequence) "<![CDATA[" with any
> character sequence in between and led out (ended) by the sequence "]]>".
>
> CDATA sections are used among other things to allow programming code to be embedded verbatimly in
> marked up text adhering to SGML/XML rules. Otherwise the characters <, >, & which are usually used
> in code need to be changed to &lt;, &gt; and &amp; which seems to be quite cumbersome.
>
> Here, from time to time a problem occurs, if the code (in any language) was defining a literal in
> the form of "]]>", which will end the CDATA section. For those, who are not aware of what a CDATA
> section consitutes, the surprise factor is high. However, it is only high, because the coders might
> not have full information about CDATA sections. Such cases occur if code embedded in CDATA sections
> is there to create programmatically CDATA sections as well.
>
> Block comments are the same: once opened everything is ignored unless the character sequences /* or
> */ are encountered. Which is actually a very simple rule. A programmer who is not aware of the
> definition of a comment might be surprised. But, hey, there is always something new to be learned
> everyday! ;)
>
> ---rony
>
> P.S.: And independently of PL/I, nestable block comments are great from time to time as they easily
> allow to comment out sections of code.
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>

--
http://www.thsitc.com Austria, Europe Skype ID: Thomas.Schneider.Wien
Yahoo ID: [hidden email] FaceBook ID: Thomas.Schneider.Wien Member
of the Rexx Languge Asscociation (www.rexxla.org) Member of the NetRexx
Developer's Team (www.netrexx.org)

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/