-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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@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 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users