hello,
Frank Atanassow wrote:
On vrijdag, sep 26, 2003, at 09:16 Europe/Amsterdam, John Meacham wrote:
On Fri, Sep 26, 2003 at 08:59:12AM +0200, Ketil Z. Malde wrote:
I think there is a problem with too much overloaded syntax. Perhaps
it is time to put non-ASCII characters to good use?
For
Brandon Michael Moore [EMAIL PROTECTED] writes:
Or was that supposed to be composition of a constructor with a function, A
. f? Function composition, and higher order functions in general are
likely to confuse an imperative programmer, but I think there isn't much
syntax can do there.
I
On Fri, Sep 26, 2003 at 08:59:12AM +0200, Ketil Z. Malde wrote:
Brandon Michael Moore [EMAIL PROTECTED] writes:
Or was that supposed to be composition of a constructor with a function, A
. f? Function composition, and higher order functions in general are
likely to confuse an imperative
Hi. I'm really new to Haskell, just learning it, and I must say I'm pretty
overwhelmed by the large variety of constructs. (=, -, \ to name a few)
Would that be \ as in TREX row variable polymorphism? Just remember most
operators are just library functions. It's only =, -, =, -, :: that
Keith Wansbrough [EMAIL PROTECTED] writes:
And I don't think - is part of the language - it only appears in the type
syntax, not term syntax. If you allow it, you have to allow * as well.
Errm, you just gave an example of - in the term syntax...
(\x - x*x) 3
Regards,
Malcolm
Keith Wansbrough [EMAIL PROTECTED] writes:
And I don't think - is part of the language - it only appears in the type
syntax, not term syntax. If you allow it, you have to allow * as well.
Errm, you just gave an example of - in the term syntax...
(\x - x*x) 3
Guilty... sorry! :-(
On vrijdag, sep 26, 2003, at 09:16 Europe/Amsterdam, John Meacham wrote:
On Fri, Sep 26, 2003 at 08:59:12AM +0200, Ketil Z. Malde wrote:
I think there is a problem with too much overloaded syntax. Perhaps
it is time to put non-ASCII characters to good use?
For instance, function composition could
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
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
Hi,
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 things their own way and it's difficult to grasp
the language by looking at examples.
int fact(int x){int t=1; while(x) t*=x--;}
int
Note I've replied to haskell-cafe. This post is a bit chatty and low on
solid answers.
On Thu, 25 Sep 2003, Sean L. Palmer 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
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
Thus, the only possible lexical interpretation is the one you first
suggested, namely a constructor A followed by a three-dot operator
A... should be split into A.. and .
I found a compromise: let's make it a lexing error! :-)
--
__( Marcin Kowalczyk
\__/ [EMAIL
Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] writes:
A...
A (constructor), then ... (operator).
This is how I understand Haskell 98 lexing rules.
Argh, I was wrong. It's A.. (qualified operator), then . (operator).
You are forgetting about the maximal munch rule. An operator
Iavor Diatchki writes:
what do people think should be the tokens produced by a haskell lexer
when applied to the following input:
A...
This has been discussed before (a while back, admittedly). See:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg04054.html
GHC (still) gets this
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
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
Dnia nie 14. wrzenia 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
Dnia pi 12. wrzenia 2003 20:31, Iavor Diatchki napisa:
what do people think should be the tokens produced by a haskell lexer
when applied to the following input:
A...
A (constructor), then ... (operator).
This is how I understand Haskell 98 lexing rules.
--
__( Marcin
On Sun, 14 Sep 2003 00:30:40 +0200
Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] wrote:
Dnia pi_ 12. wrze_nia 2003 20:31, Iavor Diatchki napisa_:
what do people think should be the tokens produced by a haskell
lexer when applied to the following input:
A...
A (constructor), then
20 matches
Mail list logo
