Re: Block comments ala Ray

[Stephane Chazelas <stephane@xxxxxxxxxxxx>]

2021-02-14 12:15:31 -0800, Bart Schaefer:
[...]
> > - those !#, #! look too much like a shebang.
> 
> Which actually doesn't matter, because #! isn't special anywhere but
> the first line.
> 
> > - !# is already histsubst syntax.
> 
> Also doesn't matter, this was intended only to operate where history
> is disabled anyway.
> 
> > - It's also the !# extendedglob
> 
> You mean "zero or more occurrences of '!' "?  This is another reason I
> was only allowing "!#" at the start of a line.  Under what
> circumstances would you begin a new line with that glob?
> 
> > - It's also (POSIXly) invoking the !# command.
> 
> Yes, I mentioned that.  It seems pretty damn unlikely to use that, as
> it has no effect other than to set $? to 1.

Those were more objections on style ground than to say it was
an incompatible change.

I can imagine someone seeing:

!#
some
code
#! end

And thinking "is that remnants of mistyped shebang?", "why 0 or
more !s?", "what's that history expansion doing in there...?".

[...]
> > - syntax is a bit obscure and uncommon.
> 
> Intentionally so, yes.  It has to be something that would essentially
> never appear in an existing script.

I rather meant "something that one would not readily associate
to a block comment", though I'll admit that none of the
alternatives I suggested are any better.

[...]
> >   Does it have to be delimited with whitespace? Can we
> >   use !########### .. ##############!? That ! is easy to miss.
> 
> Those are among the reasons I didn't think forming "inline comments"
> was a good idea.
[...]
> > - assuming we allow nesting (which would be useful to comment
> >   out sections of code that contain block comments),
> 
> I hadn't considered nesting.  You can't nest C /* ... */ comments, and
> this was not intended to work any differently.

But the only use I can imagine for those !#...#! block comments
are to comment out code. That's why you use #if 0 in C for that
(so you can comment out code that contains comments).

I wouldn't use those for commenting (for inline documentation),
just like in C, we use

/*
 * multiline
 * comment
 */

For long comments as comments formatted as:

/*

  multiline
  comment

*/

make the code less legible as it's less clear what is code and
what is comment.

I could use a C-like comment that allows me to do things like:

rsync -v --inplace \
  --stats -xazAX --delete \
  --numeric-ids !# don't want the dependency on NSS #! \
  --hardlinks

Though at the moment, we can already do:

rsync_options=( -v --inplace
  --stats -xazAX --delete
  --numeric-ids # don't want the dependency on NSS
  --hardlinks
)
rsync $rsync_options

[...]
> > Or ksh's <#((...)), <#.. <>;  redirection operators.
> 
> The possibility of wanting to add those would also argue against using
> "<#" or "<<#" as a comment introducer.

Yes, that's why I didn't suggest <#.

And also why I brought up those ksh93 operators, to suggests
there are more lexer changes that we may want to add to zsh in
the future.

Here, if it was my call, I would just not bother with a new
block-comment operator, at least not until one gave a good
reason why they would be useful and better than what we already
have.

-- 
Stephane