Announcing
==
The Haskell Report
Version 1.2
1 March 1992
The Haskell Committee, formed in September 1987 to design a "common"
non-strict purely
> Good. Let me add a disclaimer, though. This appears to me still to be
> LR-parseable (except for the genuine ambiguity), because in the absence of
> arbitrary parenthesization, a finite lookahead is sufficient to distinguish,
> for example,
>
> (n+1) x =
> from
> (n+1) `op` x =
>
>
|Joe writes:
|> [My simple syntax for LHSes] doesn't cover things like
|>
|> (f .* g) x y = f (g x y)
|
|and proposes a syntax which is the same as my simple proposal,
|but covers exactly this also.
|
|> lhs ::= (var | @(@ ilhs @)@) apat+
|> | ilhs
|> | pat
|>
|> ilhs ::= pat{i+1} varo
> Let's either disallow (n+k) pattern bindings or always resolve the
> ambiguity as an (n+k) pattern. I'd prefer the former, but I never
> use (n+k) patterns, anyway.
Likewise!
> Kevin
Ian
Joe writes:
> [My simple syntax for LHSes] doesn't cover things like
>
> (f .* g) x y = f (g x y)
and proposes a syntax which is the same as my simple proposal,
but covers exactly this also.
> lhs ::= (var | @(@ ilhs @)@) apat+
> | ilhs
> | pat
>
>
|Syntax
|~~
|* Left-hand side syntax. PROPOSED DECISION: go with Kevin's suggestion.
|It is simple, does not require modification if we abandon n+k patterns, and
|nobody has objected to it. Kevin has implemented it, and John Peterson
|(our other implementor) agrees. All agree that the prese
> * Should gd -> exp^0 be changed back to gd -> exp? PROVISIONAL DECISON: no.
> We made this choice at Mark Jones' suggestion, to allow us to write
> e::T Int rather than e::(T Int). (I can't remember why this guard stuff
> is a consequence... No action reqd.
I agree, if we don't do this, then
This is a summary of all the outstanding issues I'm aware of for Verison 1.2.
If there are others I've omitted, let me know.
Glasgow have the token for all files except the Prelude source files
themselves, which Joe has the token for.
There are actions on
Paul (check proposed syntax c
Posted on behalf of SLPJ -- KH.
Folks,
The Haskell Report is to be published in SIGPLAN Notices later this year.
The deadline for this is end February 1992.
Over the last month we have been collating and correcting all the
typographical errors and infelicities in the V1.1 report. In additio
