Qualified identifiers opinion

[Isaac Dupree]

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).

Then maybe you can join haskell-prime and provide the energy that rounds 
up all the little fixes and tries to actually produce the thing! 
Drastic changes are not intended to go in.  Haskell' should bring more 
stability and standardness (as long as it doesn't diverge too much from 
Haskell98, which would decrease stability and standardness)

> 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.)

Trouble is, extensions are just that: extensions, and more with their 
own keywords may be added in the future! unless we want an 
internet-standard-like "x-keywordname" - but that doesn't solve this 
problem: standardized new keyword names clogging up the general 
namespace, as long as they don't have a symbol (like Objective-C has 
@class, @whatever...).

> 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 "(.)"

I wouldn't mind if that was banned either. That case needs to be 
considered for implementing my lexer. In fact, banning that and 
qualified keywords allows the lexer proper not to know keywords and 
nevertheless ban qualified keywords (a bit of a hack).  But... while I 
wouldn't _recommend_ using qualified keywords, and compilers could give 
a warning even for haskell98 code that uses known 
extension-keyword-names at all, it seems best to me, to _allow_ them, in 
the interests of allowing code to remain fairly stable with the 
potential of extensions being developed (especially thinking of the 
BangPatterns that had an effect on existing definitions of (!) ).

> 
> Maybe "." and "$" as operators should require white spaces on both
> sides, since "$(" also indicates template haskell.

but it's so convenient as it is... plenty of code uses (.) without 
spaces, and I don't like the way template-haskell steals "$(" and "$id" 
(from the point of view of a person who has never tried to use 
template-haskell).

I think haskell is more stable by allowing existing code e.g.
(f = fix (\rec -> .... rec ....) --'rec' is arrow-sugar keyword
than banning some bunch of new keyword names.  And allowing interim 
interoperability with old code that exports those names, like the 
unfortunate (!) or (.) (I know, those aren't exactly ever keywords/syms) 
seems like a good idea when it removes complexity rather than adding it. 
    I don't want Haskell98 to become a language that has difficulty 
interoperating with libraries and using-applications that use newer 
Haskells.

from other comments:
>> 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 agree with Stefan, for the reasons he stated and for one additional
> reason:  There would be a multitude of unintended behavior changes.

Well, GHC doesn't implement aforementioned maximal-munch re: keywords. I 
don't think it's good (compositional?) design for the set of keywords to 
be part of the lexer rather than a pass after it, when keywords behave 
so similarly to other words, and also when there are non-keywords like 
"as" and "qualified" and sometimes "forall" (whose non-reserved status I 
support).
lex --> keywords --> layout --> parse
Besides, I don't think any of the above proposals will generate behavior 
changes in real code. Some cause more errors (adding more keywords; 
banning adjacent '.' or '$') and some allow a few more things that were 
errors before.
f = Just.let x = x in id  --a.k.a. f = Just
would break in my proposal, but it also breaks according to Haskell98...


Isaac