Block comments in Haskell.

[Kent Karlsson <kent>]

Original-Via: uk.ac.ukc; Thu, 13 Sep 90 17:47:00 BST
From: Kent Karlsson <kent>
Date: Thu, 13 Sep 90 18:00:21 +0200
To: haskell@cs.glasgow.ac.uk
Subject: Block comments in Haskell.
Original-Sender: kent%se.chalmers.cs@sunic.sunet.se
Sender: haskell-request@cs.glasgow.ac.uk

>                                           ...  Please
> let me know if your favorite problem was not fixed.

This problem is far from a favourite, but there was no proper fix...



			SOME COMMENT PROBLEMS (Sigh...)
                        =====================

Paul Hudak, on behalf of the Haskell committee, writes:
> 
> The fix is to change the rule for ncomment as follows (in which I use
> _ for subscripting, and the meta-characters < and > in place of { and } 
> to avoid conflict with the terminals { and } -- thus <foo> means zero
> or more occurrences of foo; and {foo} means the terminal { followed by
> foo followed by the terminal }.  I hope this is clear!):
> 
>   ncomment   ->   {- junk <junk> }
>   junk       ->   < any_<-> | whitestuff_<comment> > - <->
> 
> So "junk" is zero or more occurrences of any character except "-" and
> any whitespace except an unnested comment, followed by ONE OR MORE "-"s.
> 


   This is going from something which could be nearly acceptable to some-
thing definitely worse!  Not only does it contain a mistake which can make
e.g. "{- {- -}" into a *complete*  ncomment, but also (even if the mistake
was corrected) makes attempts at "commenting out" a piece of (syntactically
correct) Haskell source code a somewhat unpredictable operation, if you
don't carefully read what is "commented out", so that no strings or
non-nestable comments contain "{-" or "-}".



			THE FIRST ALTERNATIVE
			=====================

   I would rather like to make the following statement from the Haskell 1.0 
report (p. 7) true:
**********************************************************************
*  "any contiguous portion of Haskell program text may be turned     *
*   into a comment" (by surrounding it with "{-\n" and "\n-}")       *
**********************************************************************
Which is (arguably, and obviously) what both the committee and I expect.
The  ncomment  production in the report does not make the quoted statement
above true, and the suggestion (further) above makes it even less (:-?) true.

   The following production does make it true:

       ncomment -> {- {whitespace|string|{any}                                   } -}
       			                      { {any}( " | {- | -- | -} ){any} }

(where the "{" and "}" in "{-" and "-}" are not meta-characters)

or if you prefer the meta-syntax used above:

       ncomment -> {- <whitespace|string|<any>_< <any>( " | {- | -- | -} )<any> > > -}
       			                      
(This production also corrects a mistake in the  ncomment  production in the
report (p. 7), which also could make e.g. "{- {- -}" and even "{- -} -}"(!)
into *complete*  ncomments, so according to the report it is *very* hard to determine
if "{-" starts a block comment or not, and whether "-}" ends a block comment.)

   Note the new inclusion of strings within block comments, so that a string like
"XX -} YY" will *not* unexpectedly terminate a block comment.  This also means
that strings must be properly formatted within a block comment, but that is a
small price to pay, I think.


   The "C-ism"
> 	   {-----------------------------------------------
> 	   y = x
> 	       where x = 3
> 	   ------------------------------------------------}

can be written as e.g.

 	   {-**********************************************
 	   y = x
 	       where x = 3
 	   ***********************************************-}

which would not cause any problems.




			THE SECOND ALTERNATIVE
			======================

An alternative is to disallow "{-" and "-}" in non-nestable comments and
strings (having to write "{\&-" and "-\&}", or similar, instead).

	comment    -> -- {any}                          newline
	                      { {any}( {- | -} ){any} }

	stringelem -> graphic          | space | escape | gap
	                     { " | \ }

	string     -> " {stringelem}                                        "
	                            { {stringelem}( {- | -} ){stringelem} }

(where the "{" and "}" in "{-" and "-}" are not meta-characters)

and use the following corrected production, so that  ncomments can be
unambiguously nested (a mistake made in the "fix", but also in the
original production).

	ncomment   -> {- junk { ncomment junk } -}
	
	junk       -> {any | white}
	                           { {any | white}( {- | -} ){any | white} }
		
	white      -> newline | space | tab | vertab | formfeed
	
	whitestuff -> white | comment | ncomment


   This alternative solution also makes
**********************************************************************
*  "any contiguous portion of Haskell program text may be turned     *
*   into a comment" (by surrounding it with "{-\n" and "\n-}")       *
**********************************************************************
true, but now even
**********************************************************************
*  "any contiguous portion of Haskell program text may be turned     *
*   into a comment" (by surrounding it with "{-" and "-}")           *
                                               ^      ^
**********************************************************************
becomes true (though "contiguous" is still a bit vague).  The quoted
"C-ism" now becomes a complete  ncomment  (as intended by the "fix").


			/kent k