Christian Maeder wrote:
Hi Isaac,
just to give you a reply at all, see below. I reply
[EMAIL PROTECTED] 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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
