Qualified identifiers opinion

[Seth Kurtzberg]

-----Original Message-----
From: glasgow-haskell-users-bounces at haskell.org
[mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Stefan
O'Rear
Sent: Friday, August 17, 2007 2:45 PM
To: Christian Maeder
Cc: Haskell Prime; GHC Users Mailing List; Isaac Dupree
Subject: Re: Qualified identifiers opinion

On Fri, Aug 17, 2007 at 12:53:11PM +0200, Christian Maeder wrote:
> Hi Isaac,
> 
> just to give you a reply at all, see below. I reply 
> glasgow-haskell-users at haskell.org since I'm not subscribed to 
> haskell-prime. And I don't want to subscribe, because I'm more 
> interested that Haskell becomes more stable (and standard). So here is 
> my opinion:
> 
> 1. The lexer should recognize keywords.
> 
> 2. I would not mind if Haskel98 rejected all keywords that are also 
> rejected by extensions, so that the lexer is extension independent.
> (Starting with Haskell98, removing conflicting identifiers as soon as 
> I switch on valuable extensions does not make sense.)
> 
> 3. I'm against qualified identifiers, with the unqualified part being 
> a keyword like "Foo.where". (The choice of qualification should be 
> left to the user, usually one is not forced to used qualified names.)
> 
> 4. However, "Foo.where" should always be rejected and not changed to 
> "Foo.wher e"! (Longest matching, aka "maximal munch", must not 
> consider
> keywords!)
> 
> (see end of: 
> http://www.haskell.org/onlinelibrary/lexemes.html#sect2.4)
> 
> I would not mind if a name "F. " is plainly rejected. It only makes 
> sense, when a data constructor is the first argument of the 
> composition operator "(.)"
> 
> Maybe "." and "$" as operators should require white spaces on both 
> sides, since "$(" also indicates template haskell.

What's wrong with the status quo?  Our current lexical rules *seem*
complicated to newbies, but just like everything else in Haskell it carries
a deep simplicity; having only one rule (maximal-munch) gives a certain
elegance that the proposals all lack.

I'd hate to see Haskell become complex all the way down just to fix a few
corner cases; I see this pattern of simplicity degerating through
well-intentioned attempts to fix things all over the language...

Stefan

I agree with Stefan, for the reasons he stated and for one additional
reason:  There would be a multitude of unintended behavior changes.


Seth Kurtzberg
Software Engineer
Specializing in Security, Reliability, and the Hardware/Software Interface