Re: nested comments, 4

[Kent Karlsson <kent>]

Original-Via: uk.ac.ukc; Fri, 21 Sep 90 12:59:16 BST
From: Kent Karlsson <kent>
Date: Fri, 21 Sep 90 13:46:23 +0200
To: haskell@cs.glasgow.ac.uk
Subject: Re:  nested comments, 4
Original-Sender: kent%se.chalmers.cs@sunic.sunet.se
Sender: haskell-request@cs.glasgow.ac.uk

> Earlier versions of Haskell had exactly this feature.  This added
> complexity to the lexical analysis which was felt to be unjustified for
> such an infrequently used feature (the string analysis would also need
> to cope with NESTED comments, not just EOL comments, this can be
> ANNOYING for automatically generated lexers).

I think this is irrelevant, especially since Haskell has many features
that are annoying when using automatically generated parsers anyway. (:-)

>                                            There are several obvious
> advantages to reducing language complexity.

But my intention was that this sould be taken in the context of banning
nestable comments (thus greatly reducing language complexity!!).  Another
*reduction* of complexity (from the user/programmers point of view!)
would be to allow to-end-of-line comments at the end of ANY line!

> 
> You can have exactly what you want with:
> 
> 	"This is a " ++		-- This is a legal comment!
> 	"string which was written " ++
> 	"without \"gaps\" in the program."
> 
> (in odd contexts you might need to parameterise the string).  Since

"parameterise the string"???

> most compilers will fold constants, you should lose no performance
> by using this string.
> 
> It is moot whether gaps themselves are needed (given the orthogonality
> of the Haskell design, it isn't obvious that a gap can ever be used
> where ++ cannot).

"it isn't obvious that a gap can ever be used where ++ cannot"???

   A "gap" can be seen as a *very* high priority (it binds stronger than
application) concatenation of string constants. But given parenthesis
there would be no problem to eliminate "gaps" by using the (low priority)
++ operator instead.  (Isn't this obvious? :-)

>                     Eliminating gaps would restore the property that
> "--" comments could appear at the end of any line.

Then I propose to reduce language complexity by eliminating the "gap"
feature.

			/kn