Dnia nie 14. września 2003 01:04, Derek Elkins napisał:

...

...

A...

A (constructor), then ... (operator). This is how I understand Haskell 98 lexing rules.

My first thought was that it should produce, A.. ., as in (.) (A..), but obviously that would be wrong as A.. must be a function and therefore to be passed to (.) it would need to be (A..).

Argh, I was wrong. It's A.. (qualified operator), then . (operator). So it's syntax error recognized during parsing.

I take this to mean the (..) function from the Prelude module.

".." is a reserved operator, used for ranges. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

I agree with Marcin, A... should be split into "A.." and "." As I read the (on-line) report the "maximal munch" rule says that you should read the longest lexeme. It does not say that two operators have to be separated by whitespace. Because A... is not a lexeme, the longest lexeme you can read from "A..." is "A.." (qualified dot-operator). Arthur On maandag, sep 15, 2003, at 12:11 Europe/Amsterdam, Malcolm Wallace wrote:

Marcin 'Qrczak' Kowalczyk <qrczak@knm.org.pl> writes:

...

Argh, I was wrong. It's A.. (qualified operator), then . (operator).

You are forgetting about the maximal munch rule. An operator cannot appear directly next to another operator without some whitespace to separate them. For instance "A.+." is an operator called (+.) from module A, not an operator called + followed by compose.

But, although "A...." could be the three-dot operator "..." from the module A, it is not possible to have "A..." interpreted as a two-dot operator, because ".." is reserved as sugar for enumeration sequences, and so is explicitly excluded from the varsym production.

Thus, the only possible lexical interpretation is the one you first suggested, namely a constructor "A" followed by a three-dot operator "...".

Regards, Malcolm _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell

Marcin 'Qrczak' Kowalczyk wrote:

...

A... should be split into "A.." and "."

I found a compromise: let's make it a lexing error! :-)

At least that agrees with what some Haskell compilers implement. No current Haskell compiler/interpreter agrees with what the report seems to say, that is that "A..." should be lexed as the two tokens "A.." and ".", and similarly, "A.where" should be lexed as "A.wher" followed by "e". It seems that the source of the problem is the use of the (nonstandard) difference operator r1<r2> in the specification of the lexical syntax in the Haskell report [1]. It was presumably fairly innocent and easy to understand originally, but I guess that nobody understood its consequences when qualified names were introduced. Anyway, this should teach us not to use homemade pseudo formal notation when defining a new language, but to stick to well-established, well-understood, tool-supported formalisms... For the Programatica Haskell front-end, I have now switched to a regular expression compiler that has direct support for the difference operator, so hopefully, our implementation agrees with what the report specifies. (This is not necessarily a good thing, though, since it makes our front-end different from all other Haskell implementations :-) For what it is worth, I tested "A...", "A.where" and "A.--" in the main Haskell implementations and in the Programatica Haskell front-end. The input was two modules A and B: 1 module A where 2 3 wher = id 4 e = id 1 module B where 2 import A 3 4 x = (A.where) 5 y = x Here is the result: GHC: B.hs:4: parse error on input `where' HBC: "B.hs", line 4, Bad qualified name on input:<eof> Hugs: ERROR "B.hs":4 - Undefined qualified variable "A.where" NHC98: Identifier A.where used at 4:6 is not defined. PFE: ok If line 4 in module B is replaced with x = (A...): GHC: B.hs:4: Variable not in scope: `A...' HBC: "B.hs", line 4, Bad qualified name on input:<eof> Hugs: ERROR "B.hs":4 - Undefined qualified variable "A..." NHC98: Identifier A... used at 4:6 is not defined. PFE: B.hs:4,13, before ): syntax error (A.. is lexed as A.. .) If line 4 in module B is replaced with x = (A.--) GHC: B.hs:4: Variable not in scope: `A.--' HBC: "B.hs", line 5, syntax error on input:= (treats -- as the start of a comment) Hugs: ERROR "B.hs":4 - Undefined qualified variable "A.--" NHC98: Identifier A.-- used at 4:6 is not defined. PFE: B.hs:5,1, before : syntax error (A.-- is lexed as A.- -) I used the following versions GHC 6.0.1 HBC 0.9999.5b Hugs 98 November 2002 NHC98 1.16 PFE 030912 -- Thomas H [1] http://www.haskell.org/onlinereport/syntax-iso.html

Hi,

But I'm just writing this to let you guys know (surely you know this already) that anyone from a C/C++/Java/Delphi background is going to completely misunderstand the meaning of A.anything in Haskell... it's completely nonintuitive to people with my background.

Surely this is no worse than misunderstanding '=', as in:

f n = n + 1

is it? I'd say of all the hurdles going from C++-esque to Haskell, the A.foo is one of the least troubling (I could be wrong and would like to know if I am).

Haskell to me seems to be a great language with a syntax problem, and a bad case of too many ways to do the same thing; thus every programmer does

I've always thought it the opposite :). Let vs. where can be somewhat confusing, and it is largely a matter of style, but they're not completely interchangable, esp. in the presence of, say guards, ie.:

f x | x < 0 = foo x | x > 0 = foo (-x) where foo y = ...

could not be done with a let. My 2 cents... - Hal