CoCoA » CoCoA-5

As already pointed out in #469 (update 2) I think we should aim to make multiline comments obsolescent. Here are some options:
(A) eliminate the syntax /* ... */ completely, but that would make Anna's choice of prompt pointless.
(B) allow the syntax, but require that the comment be closed on the same line (rather than allowing the comment to span many lines, as currently we do).
(C) no change (yet), but keep the syntax "well-hidden" in the documentation (hoping that no one uses it)

Option (B) maintains some backward compatibility, and I do quite like the possibility of having an embedded comment in a line (I even used it in RealRoots.cpkg5); it would also accept Anna's prompt without problem.

One reason for having multiline comments is that it becomes easy to comment out blocks of code; this is also what prompted the designers of CoCoA-3 to recognise nested /*...*/ comments.

However, in CoCoA-5 the nesting of comments is not recognised/respected, so it is "dangerous" to use /*...*/ to comment out a block of code -- it won't produce the desired effect if that block of code already contains a /*...*/ comment.

The cocoa5-mode for Emacs makes it easy to comment out consecutive lines: it simply inserts -- at the start of each line; blocks may also be easily uncommented. So there is no need for a special syntax making it easy to comment out blocks of lines.

I suppose the GUI has similar capabilities for commenting and uncommenting consecutive lines (if not, surely it can be added easily).

I believe these reasons are more than sufficient to prohibit /*...*/ from delineating multiline comments.

I've updated the CoCoAManual entry; it doesn't say that /*...*/ works for multiline comments (but it doesn't forbid it either). I've removed the bit about nested comments.

Another (mild) reason for avoiding the drastic option (A) is that matrices are printed in a way which assumes that /*...*/ is a comment. This could easily be sorted out if we do adopt (A): an end-of-line comment would work just as well in this instance.

Places we should look at for changing the parser so that it warns about (or complains about) multiline comments:

LineProviders.C:73 in InteractiveLineProvider::prompt

Perhaps the best place to issue a warning would be around Lexer.C:88
just after a new line has been read (successfully) by a LineProvider.
[wish me luck!]

I have inserted the following in Lexer.C:83 right before the declaration of the variable chars (what purpose does chars serve???)

                if (this->status.isInMultiLineComment())
                  this->reportWarning("Multiline comments are OBSOLESCENT; please comment each line separately", WS_NORMAL);

It seems to behave as I want. The CoCoA-5 tests all pass (after a minor change).

Should I check it in? (yes, yes :-))

John Abbott wrote:

I have inserted the following in Lexer.C:83 right before the declaration of the variable chars (what purpose does chars serve???)
[...]

It seems to behave as I want. The CoCoA-5 tests all pass (after a minor change).

Should I check it in? (yes, yes :-))

I'm not entirely convinced, but you may.
... but I reserve the right to complain afterwards ;-)
[JAA "right to complain"? Tipica genovese!!]

CoCoA-4 had nested comments /* /* */ */.
In CoCoA-5 G.Lagorio refused to maintain that feature because "C does not allow that, and there is a good reason why" (even though I never understood why).

This, of course, makes it not backward compatible.
That said, I like multiline comments (and I have a macro to emulate that in LaTeX ;-)
Anyway I use the emacs interface, so I have no problems in making "Comment Region" with the -- syntax ;-)

NOTE 20140318 The point is that YOU must be careful when writing multiline comments; if you should accidentally put a /* or a */ in your comment then strange things will happen -- if you put /* in your comment then CoCoA will notice the error only when it reaches the end-of-file (and it cannot give you much help locating the true cause!)

Here is why I think nested "multiline" comments are problematic; essentially the parser is compelled to parse the comments as though they were code, but comments can contain "any old junk".

Consider what happens when you try to comment out this function:

Define JAA(x)
  If x < 0 Or IsPrime(x) Then --> easy if x is *negative*/*prime*
    Return 0;
  EndIf;
  Return 1;
EndDefine;

I'm definitely with Giovanni on this question.

NOTE 20140323 there is also the point that the designers of C/C++ chose not to have nested comments, and they're surely smarter/more experienced than we are...

I suggest adding a warning if /* is found inside a /*...*/ comment. This would alert users to a (probable?) presence of nested comments.

Relevant code: Lexer.C:247--261

What do you think?