smuj wrote:
> Jon Lang wrote:
>> smuj wrote:
>>> Jon Lang wrote:
>>>> Here's a radical notion: use something other than '#' to initiate an
>>>> inline comment.
>>> [snippage]
>>> Or maybe just don't allow "embedded" comments unless they are actually
>>> "embedded", i.e. if a line starts with a # (ignoring leading whitespace)
>>> then it's _always_ a line-end comment, no matter what follows the #, e.g.
>> That has the advantage of preserving a three-character embedded
>> comment.  It has the disadvantage that you get differing behavior
>> depending on where the comment is on the line.  As I see it, the whole
>> point of this exercise is to get rid of the gotchas, and not just to
>> shift them around - thus my ':#' proposal.
> I think whatever the solution is, it must begin with a # -- anything else
> will likely create even more gotchas.

When inline comments begin with a '#', the main gotcha arises when you
go to comment out a series of lines by prepending a # to each, and one
of those lines begins with the proper series of characters to create
an inline comment instead.  If you add the condition that a line
beginning with a '#' is automatically a full-line comment (or, as
currently specced, simply complains about the ambiguity), you replace
this gotcha with one where someone types in what he intends to be an
inline comment, but forgets to indent it.  Adding a secondary
character after the '#' reduces the likelihood of this happening, but
doesn't eliminate it.

When inline comments begin with something other than '#', none of the
above gotchas exist.  Instead, the main gotcha occurs when you go to
create an end-of-line comment at the end of a line that ends with
whatever the first character of an inline comment is.  A programmer
who forgets to put whitespace between that character and the '#' will
get an inline comment instead.  IMHO, this is no different than any
other case where the programmer mistakenly allows two different tokens
to run together.  As well, when programmers add comments to the ends
of a series of lines, they generally lead off with whitespace intended
to align said comments with each other; so existing habits would not
cause difficulties as they currently do for commenting out lines.

> Also, we have to realize that no
> matter what sequence we choose for embedded comments, there will _always_ be
> a chance of a gotcha, so all we can do is minimize the likelihood, as well
> as making the gotcha easy to spot, whilst not making embedded comments too
> difficult to use for those who like them.

My argument is that starting an inline comment with something other
than a '#' minimizes the likelihood of gotchas, makes gotchas easy to
spot, and doesn't make embedded comments too difficult to use for
those who like them.  Is there anything that my argument missed?

> My current personal favourite would be to keep things as they are with
> regards to bracketing, but to introduce a + between the # and the brackets.

This reduces the likelihood of ambiguity cropping up between an
embedded comment and an end-of-line comment; but it doesn't eliminate
the possibility.  Reversing the order to '+#' _would_ eliminate any
possibility of ambiguity at the start of a line; and the only thing
you'd have to watch out for would be someone deciding to start an
end-of-line comment immediately after a '+', with no intervening
whitespace.  As well, '+#' is just as easy to type as '#+'.  Heck,
while I like the bracketing idea, you could even say that any comment
that begins with '+#' followed immediately by a non-bracketing
character is an inline comment that will be terminated by the first
'#+' sequence it finds:

  #end-of-line comment
  #(end-of-line) comment
  #+end-of-line comment
  #+(end-of-line) comment
  +# embedded comment #+
  +#(embedded comment)

I'm not picky as to the choice of the additional character; but if
you're going to add it in, add it in where it will cause the least
amount of trouble: just before the '#'.

> I'd also change the terminology from "embedded" comments to "extended"
> comments.

toMAYto, toMAHto.

Jonathan "Dataweaver" Lang

Reply via email to