...

-- followed by a symbol does not start a comment, thus for example, haddock declarations must begin with -- |, and not --|.

What might --| mean, if not a comment? It doesn't seem possible to define it as an operator.

GHCi, at least, allows it.

Prelude> let (--|) = (+) Prelude> 1 --| 2 3

I believe the motivating example that persuaded the Language Committee to allow these symbols was --> which is not of course used anywhere in the standard libraries, but is an extremely nice symbol to have available in user code. Regards, Malcolm

On 3 June 2011 19:19, Guy wrote:

On 03/06/2011 12:01, Malcolm Wallace wrote:

...

I believe the motivating example that persuaded the Language Committee to allow these symbols was      --> which is not of course used anywhere in the standard libraries, but is an extremely nice symbol to have available in user code.

Seeing as no library actually defines such a symbol, is it worth forcing an extra space into comments? --| and --^ would be an extremely nice symbols for haddock comments.

We already have to forms of comments: -- and {- -}; why do we need another two? Think of it this way: the "--" defines the comment, and then we use the "|" or "^" to indicate to _haddock_ to interpret this differently. I don't think we need to special-case symbols starting with "--" just to avoid having to put a space in to delimit the comment indicator and the markup indicator. That said, I have a use for --> as a symbol... if it wasn't that I'd also want something like -- to follow suit, and as such it'll just be easier to use something like .->. and .--. (for creating directed and undirected edges respectively in graphs). -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

2011/6/3 Guy :

I wasn't proposing additional comment symbols; I'm proposing that anything beginning with -- is a comment.

I use --> as a infix operator to describe types in Template Haskell. So I too oppose your proposal. ;)

On 03/06/2011 05:02 PM, Albert Y. C. Lai wrote:

I propose that only {- -} is comment; that is, -- is an operator token and not a marker of comments.

I'm curious to know why anybody thought that "--" was a good comment marker in the first place. (I'm curious because Haskell isn't the only language to have made this strange choice.) I once tried defining a "++" operator and then when I went to define a matching "--" operator...

Roman Cheplyaka writes:

* Andrew Coppin [2011-06-03 18:12:04+0100]

...

On 03/06/2011 05:02 PM, Albert Y. C. Lai wrote:

...

I propose that only {- -} is comment; that is, -- is an operator token and not a marker of comments.

I'm curious to know why anybody thought that "--" was a good comment marker in the first place. (I'm curious because Haskell isn't the only language to have made this strange choice.)

It is, for my taste, a good comment marker, because of its resemblance to a dash. It makes the code look like real text:

let y = x + 1 -- increment x

And when the language was first defined, there was no real dash available for this purpose. Nowadays we could use the unicode em dash (U+2014, "—" if it survices nntp), and free up -- for other purposes. Of course, its hard to predict what effect this would have when people didn't know how to enter it, and although it's quite distinctive in proportional fonts, the difference between - and — in monospace fonts is much harder to see. -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2010-09-14)

*Touché.* Nice one. 2011/6/4 Albert Y. C. Lai

On 11-06-04 02:20 AM, Roman Cheplyaka wrote:

...

It is, for my taste, a good comment marker, because of its resemblance to a dash. It makes the code look like real text:

let y = x + 1 -- increment x

COBOL is real text, if that is what you want.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 4/06/2011, at 5:12 AM, Andrew Coppin wrote:

I'm curious to know why anybody thought that "--" was a good comment marker in the first place. (I'm curious because Haskell isn't the only language to have made this strange choice.)

Indeed. The Wikipedia lists Euphoria, Haskell, SQL, Ada, AppleScript, Eiffel, Lua, and VHDL. Presumably it was chosen for its resemblance to the em dash. SNOBOL had a neat hack. You could begin a comment with any of ⎡⎢⎣ making it possible to write blocks that looked like ⎡ A comment that ⎢ stretches over ⎣ several lines. APL's "lamp" symbol had the advantage of being wholly new and so having no prior conflicting uses. ⍝ has been in Unicode for a relatively long time. Bearing in mind that the characters that have been used to begin end of line comments include *, /, ;, !, #, %, and $, it's not clear that there's anything _that_ regrettable about "-- ".

Nicolas Wu schrieb:

This whole discussion is reminding me of Wadler's Law of Language Design [1], it's nice to see that in 15 years things haven't changed much!

WADLER'S LAW OF LANGUAGE DESIGN In any language design, the total time spent discussing a feature in this list is proportional to two raised to the power of its position. 0. Semantics 1. Syntax 2. Lexical syntax 3. Lexical syntax of comments

[1] http://www.informatik.uni-kiel.de/~curry,/listarchive/0017.html

It's the first time, that I see a discussion about comment syntax in Haskell-Cafe.

On Montag, 6. Juni 2011, 19:08, Albert Y. C. Lai wrote:

...

Bearing in mind that the characters that have been used to begin end of line comments include *, /, ;, !, #, %, and $, it's not clear that there's anything _that_ regrettable about "-- ".

Recall that the problem is not with isolated characters, but whole strings.

"-- a" is a comment, "--a" is a comment, but "---a" is not.

It is. Report, section 2.3: 'An ordinary comment begins with a sequence of two or more consecutive dashes (e.g. --) and extends to the following newline. The sequence of dashes must not form part of a legal lexeme. For example, “-->” or “|--” do not begin a comment, because both of these are legal lexemes; however “-- foo” does start a comment.' A sequence of two or more dashes does not begin an end-of-line-comment if and only if it is part of a lexeme containing only symbols and at least one non-dash symbol. It might be a good idea to include whitespace in the comment delimiter: end-of-line-comment is begun by whitespace--{-}whitespace.

On Monday 06 June 2011, 19:51:44, Albert Y. C. Lai wrote:

On 11-06-06 01:34 PM, Daniel Fischer wrote:

...

On Montag, 6. Juni 2011, 19:08, Albert Y. C. Lai wrote:

...

Recall that the problem is not with isolated characters, but whole strings.

"-- a" is a comment, "--a" is a comment, but "---a" is not.

It is. Report, section 2.3: Sorry. Then "--|" is not a comment. In C++, "//|" is a comment (compare with Haskell's "--|"!).

True. But then, to my knowledge, C++ has a fixed small set of operators, so the problem of a comment delimiter possibly being part of a different lexeme doesn't arise there. There is, however, a somewhat similar problem in C and C++: z = *x/*y; // oops */ Back to Haskell: I agree, the choice of the comment delimiter was not the best in light of the possibility to define operators containing it as a substring. But changing it to have "--|" start a comment too might break too much code (and eliminating "--" as a comment starter would certainly break far too much code).

On 06/06/2011 22:14, Evan Laforge wrote:

...

Back to Haskell: I agree, the choice of the comment delimiter was not the best in light of the possibility to define operators containing it as a substring. But changing it to have "--|" start a comment too might break too much code (and eliminating "--" as a comment starter would certainly break far too much code).

I like that you have to put a space in for haddock comments.

I originally posted because I found that --| stood out much more clearly as a structured comment than -- |.

On 07/06/2011 10:45, Ivan Lazar Miljenovic wrote:

On 7 June 2011 17:41, Guy wrote:

...

On 06/06/2011 22:14, Evan Laforge wrote:

...

...

Back to Haskell: I agree, the choice of the comment delimiter was not the best in light of the possibility to define operators containing it as a substring. But changing it to have "--|" start a comment too might break too much code (and eliminating "--" as a comment starter would certainly break far too much code).

I like that you have to put a space in for haddock comments.

I originally posted because I found that --| stood out much more clearly as a structured comment than -- |.

How does a missing space character make that stand out any more? :/

(Admittedly, I rely more on emacs using a different colour for Haddock comments than non-Haddock comments.)

Try it without emacs :-)

On 07/06/2011 10:55, Ivan Lazar Miljenovic wrote:

On 7 June 2011 17:50, Guy wrote:

...

On 07/06/2011 10:45, Ivan Lazar Miljenovic wrote:

...

On 7 June 2011 17:41, Guy wrote:

...

I originally posted because I found that --| stood out much more clearly as a structured comment than -- |.

How does a missing space character make that stand out any more? :/

(Admittedly, I rely more on emacs using a different colour for Haddock comments than non-Haddock comments.)

Try it without emacs :-)

I've also read un-highlighted Haskell code; I don't see "--|" standing out any more than "-- |" does. My guess is that you just get used to it...

Another argument against special-casing "--|": what happens if you want to use a _different_ documentation generator (I don't know why you would, but someone might) than Haddock, which uses a different markup identifier?

Out of interest, is there any other language where the comment delimiter is invalid if immediately followed by a symbol? Haskell seems to be parsing -- as if it was an operator (hence other legal lexemes could mean something else). Other languages say "stop parsing here", so the comment delimiter can be followed by anything. (I could, of course, be completely wrong there.)

On 7/06/2011, at 9:36 PM, Guy wrote:

Out of interest, is there any other language where the comment delimiter is invalid if immediately followed by a symbol?

Not exactly what you asked, but in some implementations of Algol, comment This is a comment; commentThis is a syntax error; And in the documentation of the M4 macro processor, where changecom(L,R) sets left and right delimiters for comments and changequote(L,R) sets left and right delimiters for quoting, the effect of having one of these left delimiters a prefix of the other is undefined. When it happens by accident the results are, well, confusing. But after doing changecom(dnlx) you find that dnl xyz is a call to the built in macro "Discard until New Line", while dnlx yz is a comment. There have been Prolog systems on IBM machines where the set of legal tokens depended on which operators had been declared. For example, if you had declared -- as an operator, then ---- was two -- tokens, but otherwise four - tokens. What they did with comments I shudder to think.

On 8 June 2011 18:13, Ketil Malde wrote:

Guy writes:

...

Out of interest, is there any other language where the comment delimiter is invalid if immediately followed by a symbol?

Another quaint example, in shell scripts, lines starting with '#' are comments, except when the first line starts with '#!'.  Admittedly, this is still a comment as far as the shell is concerned, it's the OS that is intercepting the comment's contents and acting on it.

And #! in the first line is also treated as a comment in Haskell code so that you can run it as a script. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

On 07/06/2011 10:55, Ivan Lazar Miljenovic wrote:

Another argument against special-casing "--|": what happens if you want to use a _different_ documentation generator (I don't know why you would, but someone might) than Haddock, which uses a different markup identifier?

We can declare new operators - why not new comment delimiters? That way Haddock could define --| and --^, other generators could declare whatever they wanted. The downside of this is that Haddock would have to be imported into every file which uses the markup.

On 2011-06-06 13:39 -0400, Nick Bowler wrote:

On 2011-06-06 13:08 -0400, Albert Y. C. Lai wrote:

...

Recall that the problem is not with isolated characters, but whole strings. [...] in LaTeX, "%%@#$&^*" is a comment.

This example probably does not help your position.

Since (La)TeX allows the comment character to be changed at any time, the above is not necessarily a comment. Furthermore, even with the default character classifications, \% does not introduce a comment. \% not introducing a comment in (La)TeX doesn't seem a whole lot different from --- not introducing a comment in Haskell.

And as was pointed out elsethread, --- /does/ in fact introduce a comment in Haskell. So the above should read: \% ... doesn't seem a whole lot different from --| ... -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

On Fri, 03 Jun 2011 12:19:31 +0300, Guy wrote:

On 03/06/2011 12:01, Malcolm Wallace wrote:

...

I believe the motivating example that persuaded the Language Committee to allow these symbols was --> which is not of course used anywhere in the standard libraries, but is an extremely nice symbol to have available in user code.

Seeing as no library actually defines such a symbol, is it worth forcing an extra space into comments? [..]

That's not true, xmonad[0] for example defines a -->-operator; and I would find making exceptions for --| and --^ very inconsistent and annoying. [0] http://xmonad.org/xmonad-docs/xmonad/XMonad-ManageHook.html#v%3A--%3E

On Fri, Jun 3, 2011 at 05:19, Guy wrote:

On 03/06/2011 12:01, Malcolm Wallace wrote:

...

I believe the motivating example that persuaded the Language Committee to allow these symbols was      --> which is not of course used anywhere in the standard libraries, but is an extremely nice symbol to have available in user code.

Seeing as no library actually defines such a symbol, is it worth forcing an extra space into comments? --| and --^ would be an extremely nice symbols for haddock comments.

http://xmonad.org/xmonad-docs/xmonad/XMonad-ManageHook.html#v%3A--%3E