Qualified identifiers opinion

[Simon Marlow]

Stefan O'Rear wrote:
> 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...

I believe the solution we adopted for GHC 6.8.1 (and I proposed for 
Haskell') strikes the right balance.

M.where is lexed as an identifier.  This doesn't require adding any 
exceptions or corner cases to either the implementation or the 
specification of the grammar.  It is much easier to implement than the 
existing Haskell 98 rule (I deleted 30 lines of code from GHC's lexer to 
implement it).  It's easy to understand.  It removes an opportunity for 
obfuscation.  It must be the right thing!

Cheers,
	Simon