Re: why not just use C /* ... */ ?

[Damien Neil]

On Thu, Aug 24, 2000 at 08:41:46AM +1000, iain truskett wrote:
> Does it try to parse other escape sequences (such as \t, \n, \r etc.) or
> just the Unicode one?

No, just the Unicode escapes.  Think of it as trigraphs in C -- it's
there so you can translate code from a more-featureful character set
into less-expressive one, without losing information.

> If just the Unicode one then I'd say the problem is a feature, not a
> bug (reversing my stance), but one we probably don't have to worry about
> since it's peculiar to Java. Right?

This might have some relevance to Unicode handling in Perl, but that's
a whole other can of fish.

- Damien

Re: why not just use C /* ... */ ?

[iain truskett]

* Damien Neil ([EMAIL PROTECTED]) [24 Aug 2000 08:27]:
> On Thu, Aug 24, 2000 at 06:53:31AM +1000, iain truskett wrote:
> > >/* File: C:\user\jv\demo.java */
> > 
> > > t.java:1: Invalid escape character.
> > > /* File: C:\user\jv\demo.java */

> > In that situation, I would say that the java compiler isn't really
> > doing what it should be doing. i.e. That looks like a bug, not a
> > feature.  gcc does no such thing with its comments.

> That would be because gcc is a C compiler, not a Java compiler.

> Java permits you to write Unicode characters as escape sequences like
> this: \u1234.  This translation can occur within comments, and the
> above comment contains an illegal \u escape sequence.

Aah. Now it makes sense (amazing how little of Java one can learn in two
years when one doesn't like the basic syntax of it).

Does it try to parse other escape sequences (such as \t, \n, \r etc.) or
just the Unicode one?

If just the Unicode one then I'd say the problem is a feature, not a
bug (reversing my stance), but one we probably don't have to worry about
since it's peculiar to Java. Right?

It's a gotcha, but not a drastic one.


cheers,
-- 
iain truskett, aka Koschei.
  "But you have access to the greatest source of knowledge in the
 Universe!"
  "Well...I do talk to myself sometimes, yes..."

Re: why not just use C /* ... */ ?

[Damien Neil]

On Thu, Aug 24, 2000 at 06:53:31AM +1000, iain truskett wrote:
> >/* File: C:\user\jv\demo.java */
> 
> > t.java:1: Invalid escape character.
> > /* File: C:\user\jv\demo.java */
> 
> In that situation, I would say that the java compiler isn't really doing
> what it should be doing. i.e. That looks like a bug, not a feature.  gcc
> does no such thing with its comments.

That would be because gcc is a C compiler, not a Java compiler.

Java permits you to write Unicode characters as escape sequences
like this: \u1234.  This translation can occur within comments, and
the above comment contains an illegal \u escape sequence.

  - Damien

Re: why not just use C /* ... */ ?

[Michael Mathews]

iain truskett said:

> Well, personally I was busy with work and uni. Still am, but less
> so.

My chide was only meant nicely. Of course everyone's experience and insight
is a needed contribution to the discussion.

> I'd say that no RFC should be frozen until the deadline for all RFCs.
> People can come up with the strangest insights given sufficient time
> with ideas just churning in their mind.

I suspect we all agree with you really, however setting a short deadline is
a good trick for setting a fire under a discussion to get it going. I
personally would welcome some further refinements on the RFC though, since
(as you might be able to tell) I'm not totally satisfied with how it ended
up.

--Michael

Re: why not just use C /* ... */ ?

[Michael Mathews]

iain truskett noted:
> Anyway: rfc5 claims to be frozen so this is probably a useless
> discussion anyway.

Hmmm yes, there is that litle detail. So where was all this insightful
discussion two weeks ago!!?? Hmmm??!!!

Actually I might ask the Librarian for some flexibility on this if anyone
can first make the case that they have a comment to add that isn't already
represented in the current RFC5.

--Michael

Re: why not just use C /* ... */ ?

[iain truskett]

* Johan Vromans ([EMAIL PROTECTED]) [24 Aug 2000 06:59]:
> iain truskett <[EMAIL PROTECTED]> writes:

> > > With SLC, discarding a line if it starts with a # (after optional
> > > whitespace) is straightforward, fail safe, and fast.
> > 
> > Almost. You can have # in other places on the line. It doesn't have
> > to be at the start (with or without whitespace).

> I was aiming at the case where SLC are used instead of MLC. In this
> case, every line is commented out, hence the # will always be at the
> line start.

># This # part
># is /* commented */
># out completely
> vs.
>/*
>This # part
>is /* commented */
>out completely
>*/

> For normal comments, your remark stands.

Hmm. I think I'm thinking differently. In my mind, using SLC markers for
MLC is still using SLC not MLC. It's fudging. The main problem I
personally have with using SLC for MLC purposes is aesthetics --- all
the lines get indented (typically) 2 chars. Do this multiple times and
your lines start getting noticeably longer.

Yes, it's faster since the interpreter finds the character straight
away. Is it elegant? No. Why? Read on!

Yes, it's clearer if your editor doesn't support highlighting. After
all, most C programmers I know (including myself) use comments in the
form:

/* Moo
 * Quack
 * This is a rather dull comment.
 * It doesn't mean much.
 */

Admittedly, my editor puts in the extra * marks. The only time I can
recall not doing comments like that was when I was including all the
documentation in the file in a man-like format.

The drawback is you have to enter it on every line. Yes, editors can do
this easily --- and no doubt many people have existing macros that do
such a comment given a mark (I would but I rarely use such commenting).

That is: It's far easier to mark an area at the top and then go to the
bottom than drop a mark at the top and then do a mystic keypress at the
bottom.


Is it easy to construct suitable macros to remove a level of commenting
without confusing two adjacent MLCs? I don't think so and I believe this
is where a proper MLC structure would be good.

Anyway: rfc5 claims to be frozen so this is probably a useless
discussion anyway. (If anyone feels like it: email me the antonym for
'moot'.)


cheers,
-- 
iain truskett, aka Koschei.
  "I'd just like to take this opportunity to say: Iain Truskett, you
  are a scheming Swine!" -- Erik Pollitt, The Barmy Army, 2621.

Re: why not just use C /* ... */ ?

[Michael Mathews]

You are certainly not the first nor only person to say this. You should know
that this point-of-view is listed in the final RFC, although it is not quite
the majority opinion of all the comments I've received.

--Michael

Johan Vromans said:
>
> In my opinion, there is no need in Perl for multi-line comments at
> all.
>

Re: why not just use C /* ... */ ?

[iain truskett]

* Johan Vromans ([EMAIL PROTECTED]) [24 Aug 2000 06:39]:
> iain truskett <[EMAIL PROTECTED]> writes:

> > It's not *that* slow. Just means the parser is looking for /* as
> > well as */ ...

> And "/*" and ""/*" and '/*' and qw(*/) and #*/ and \#*/ and m/.*/ ...

Of course. But see below.

> With MLC, you need to _parse_ the comments. What happens if you find a
> unterminated quoted string in a commented out section?  Guess what
> happens when you have the following comment in a java program:

>/* File: C:\user\jv\demo.java */

> t.java:1: Invalid escape character.
> /* File: C:\user\jv\demo.java */

In that situation, I would say that the java compiler isn't really doing
what it should be doing. i.e. That looks like a bug, not a feature.  gcc
does no such thing with its comments.

> With SLC, discarding a line if it starts with a # (after optional
> whitespace) is straightforward, fail safe, and fast.

Almost. You can have # in other places on the line. It doesn't have to
be at the start (with or without whitespace).

i.e. print # this is a print statement
$foobar # this is still the print statement
, # a comma!
/moo#/ # here's the comment
,$#array,# another one.
q#moo# # ooh!
; # ok. i'm done.

You still have to parse.


cheers,
-- 
iain truskett, aka Koschei.
 Q: How do I find the largest element in an array?
 A: Write a foreach elements one at a time, and stop when you get to
the largest one. -- perliaq.

Re: why not just use C /* ... */ ?

[Johan Vromans]

iain truskett <[EMAIL PROTECTED]> writes:

> > With SLC, discarding a line if it starts with a # (after optional
> > whitespace) is straightforward, fail safe, and fast.
> 
> Almost. You can have # in other places on the line. It doesn't have to
> be at the start (with or without whitespace).

I was aiming at the case where SLC are used instead of MLC. In this
case, every line is commented out, hence the # will always be at the
line start.

   # This # part
   # is /* commented */
   # out completely
vs.
   /*
   This # part
   is /* commented */
   out completely
   */

For normal comments, your remark stands.

-- Johan

Re: why not just use C /* ... */ ?

[Johan Vromans]

[Quoting Michael Mathews, on August 23 2000, 11:45, in "Re: why not just use"]
> Really, why? I have yet to hear any C or Java programmers complain
> about the fact that you cannot nest /*...*/ comments.

In their official (published!) coding standards, Sun explicitly states
that one should use the // comments to comment out larger chunks of
code (sec. 5.1.4).
http://java.sun.com/docs/codeconv/html/CodeConventions.doc4.html

In my opinion, there is no need in Perl for multi-line comments at
all.

-- Johan

Re: why not just use C /* ... */ ?

[Johan Vromans]

iain truskett <[EMAIL PROTECTED]> writes:

> It's not *that* slow. Just means the parser is looking for /* as well as
> */ ...

And "/*" and ""/*" and '/*' and qw(*/) and #*/ and \#*/ and m/.*/ ...

With MLC, you need to _parse_ the comments. What happens if you find a
unterminated quoted string in a commented out section?
Guess what happens when you have the following comment in a java
program:

   /* File: C:\user\jv\demo.java */

t.java:1: Invalid escape character.
/* File: C:\user\jv\demo.java */
   ^

With SLC, discarding a line if it starts with a # (after optional
whitespace) is straightforward, fail safe, and fast.

-- Johan

Re: why not just use C /* ... */ ?

[Nick Ing-Simmons]

Michael Mathews <[EMAIL PROTECTED]> writes:
>
>Really, why? I have yet to hear any C or Java programmers complain about the
>fact that you cannot nest /*...*/ comments.

Well _this_ C programmer just does

#if 0

#endif 

And come to that 

if (0) {


}

in perl.

-- 
Nick Ing-Simmons

Re: why not just use C /* ... */ ?

[David L. Nicol]

> If the prime argument for mlc is commenting out large blocks of code
> then you'd better solve the nesting problem -- and do it well.


vi substitution 

:.,+20s/^/##obsoleted Aug 22, 2000 ## /

works really well for the large blocks of code problem, so do

$BOGUS::Comment=<

Re: why not just use C /* ... */ ?

[Michael Mathews]

iain truskett said
> Hmm. Just reread RFC5 and it doesn't really come out with a strong
> recommendation of anything --- as it says "no clear concensus after [a]
> week's discussion". MLCs are a good thing --- they're just tricky to get
> right.

I'm afraid this is just plain true. As the maintainer of this RFC I feel
bound to include an accurate portayal of the comments that were submitted
while it was under debate, and the most accurate description is that there
is no consensus. This should be evident by the fact that some of the very
first suggestions are being brought up again, after already being argued
down on the List.

> Get an editor that supports syntax highlighting (e.g. vim or emacs).
> It'll improve your life no end. Makes things like this easier since it
> will colour distinctly what it believes to be comment.

This type of suggestion came up frequently during the debate (the "keep a
particular functionality on the desktop" argument), but if you are going to
open that door, why not just say 'get a text-editor that can "pound-out" all
the lines of code you want commented?', thereby negating this whole
discussion! I however think that is a bad way to go, maybe because I spent a
lot of time writing Perl on platforms and in text-editors dictatated by
someone else (who was paying me), including Macintosh BBEdit and WinNT
HomeSite (proves me stupid or versatile -- you decide). If a feature is
worth having and we programmers all want it, why should we have to mess
around trying to get crappy text-editor X, Y or Z to do it?

> Just make sure you get the appropriate RFC amended to hold your views if
> you think they're better. Or make a new RFC.

I already did. As did Glenn Linderman. I forward this invitation on to
eveyone else who interested in working to make Perl 6 better.

--Michael

Re: why not just use C /* ... */ ?

[iain truskett]

* Michael Mathews ([EMAIL PROTECTED]) [24 Aug 2000 01:48]:
> Johan Vromans said
[...]
> > If the prime argument for mlc is commenting out large blocks of code
> > then you'd better solve the nesting problem -- and do it well.

> Really, why? I have yet to hear any C or Java programmers complain
> about the fact that you cannot nest /*...*/ comments.

I do. It means that in C if I want to comment out a large part of code I
tend to use an '#ifdef 0 ... #endif' preprocessor command rather than
using good ol' C /* ... */. It's messy. And Java (typically) has no
preprocessor (I usually use cpp with javac).

[...]
> This topic has already been discussed to an extent, and actually if
> you read the RFC5 you'll see that the final recommendation is for a
> syntax that does allow for nesting, but I am not really satisfied with
> it and that's why I don't like the idea.

Hmm. Just reread RFC5 and it doesn't really come out with a strong
recommendation of anything --- as it says "no clear concensus after [a]
week's discussion". MLCs are a good thing --- they're just tricky to get
right.

[...]
> Comments should not need to be parsed by the Perl interpretter (Glenn
> L.  originally pointed this out). If nesting is allowed using a
> /*...*/ syntax, then the parser will be forced to go through the
> entire comment counting openers and closers until it gets back to zero
> and only then will it know the outermost comment is ended. [...] This
> is slow.

It's not *that* slow. Just means the parser is looking for /* as well as
*/ and is keeping track just bumping up a counter. It's not as if it's
storing the line numbers in an ever expanding list.

> This is prone to the same kind of problem you say you
> want to fix: if the random code within happens to have a stray comment
> opener or closer its up to you to track down the source of your broken
> house of comments (have fun!).

Get an editor that supports syntax highlighting (e.g. vim or emacs).
It'll improve your life no end. Makes things like this easier since it
will colour distinctly what it believes to be comment.

> If however we use unique tokens to identify comment nest-levels (as
> RFC5 proposes)...

(Amongst other things.)

[...]
> > In any case, commenting out large blocks (more than one visual page)
> > is highly confusing unless you can clearly see what is commented
> > out, for example, by prefixing every line with a '#' or so.

> This is still an option, under every proposal here. No one proposing
> that "there isn't more than one way to do it!"

Just make sure you get the appropriate RFC amended to hold your views if
you think they're better. Or make a new RFC.


cheers,
-- 
iain truskett, aka Koschei.
  "I'd just like to take this opportunity to say: Iain Truskett, you
  are a scheming Swine!" -- Erik Pollitt, The Barmy Army, 2621.

Re: why not just use C /* ... */ ?

[Michael Mathews]

Johan Vromans said
> mm> Nesting is a problem you don't really want to solve, in my opinion.
The
> mm> world gets real weird, real fast when you can nest and/or overlap
comments.
> mm> Not worth the trouble.
>
> If the prime argument for mlc is commenting out large blocks of code
> then you'd better solve the nesting problem -- and do it well.

Really, why? I have yet to hear any C or Java programmers complain about the
fact that you cannot nest /*...*/ comments.

There are no "prime arguments" here, just a collection of different points
of view.

> Especially when commenting out large blocks of code one can easily get
> into the situation that a part of a block is commented out, and then
> the whole block gets commented out. We do not want the inner comment
> to terminate the outer one, do we?

This topic has already been discussed to an extent, and actually if you read
the RFC5 you'll see that the final recommendation is for a syntax that does
allow for nesting, but I am not really satisfied with it and that's why I
don't like the idea. Here's why:

Comments should not need to be parsed by the Perl interpretter (Glenn L.
originally pointed this out). If nesting is allowed using a /*...*/ syntax,
then the parser will be forced to go through the entire comment counting
openers and closers until it gets back to zero and only then will it know
the outermost comment is ended.

This is slow. This is prone to the same kind of problem you say you want to
fix: if the random code within happens to have a stray comment opener or
closer its up to you to track down the source of your broken house of
comments (have fun!).

If however we use unique tokens to identify comment nest-levels (as RFC5
proposes) this problem goes away, only to be replaced by the problem of what
to name each new comment layer (since they must all be unique). Glen
suggests adding a time stamp to the token but you can see how tedious this
all becomes.

> In any case, commenting out large blocks (more than one visual page)
> is highly confusing unless you can clearly see what is commented out,
> for example, by prefixing every line with a '#' or so.

This is still an option, under every proposal here. No one proposing that
"there isn't more than one way to do it!"

--Michael

Re: why not just use C /* ... */ ?

[Dave Storrs]

On 23 Aug 2000, Johan Vromans wrote:

> In any case, commenting out large blocks (more than one visual page)
> is highly confusing unless you can clearly see what is commented out,
> for example, by prefixing every line with a '#' or so.


I don't generally have trouble with this...most editors these days
provide syntax highlighting to show what is a comment and what is not.

Dave

Re: why not just use C /* ... */ ?

[Dave Storrs]

On Tue, 22 Aug 2000, Michael Mathews wrote:

> Tom Christiansen said:
> > Because they don't nest.
> 
> Nesting is a problem you don't really want to solve, in my opinion. The
> world gets real weird, real fast when you can nest and/or overlap comments.
> Not worth the trouble.


I disagree...being able to nest comments is *very* important.
When I comment out a the last 572 lines of my program, I don't want to
have to remove every comment in there.

I agree, however, that overlapping comments is a Bad Thing.

Dave

Re: why not just use C /* ... */ ?

[iain truskett]

* Johan Vromans ([EMAIL PROTECTED]) [23 Aug 2000 18:25]:
[...]
> In any case, commenting out large blocks (more than one visual page)
> is highly confusing unless you can clearly see what is commented out,
> for example, by prefixing every line with a '#' or so.

Or use an editor which colours it, say, green.


cheers,
-- 
iain truskett, aka Koschei.
 "Green is the colour for aliens." --- Terrance Dicks.
 "Comments are typically alien to code." --- Iain Truskett.

Re: why not just use C /* ... */ ?

[Johan Vromans]

"Michael Mathews" <[EMAIL PROTECTED]> writes:

> Nesting is a problem you don't really want to solve, in my opinion. The
> world gets real weird, real fast when you can nest and/or overlap comments.
> Not worth the trouble.

If the prime argument for mlc is commenting out large blocks of code
then you'd better solve the nesting problem -- and do it well.
Especially when commenting out large blocks of code one can easily get
into the situation that a part of a block is commented out, and then
the whole block gets commented out. We do not want the inner comment
to terminate the outer one, do we?

In any case, commenting out large blocks (more than one visual page)
is highly confusing unless you can clearly see what is commented out,
for example, by prefixing every line with a '#' or so.

-- Johan