#3766: Parsing of lambdas is not consistent with Haskell'98 report.
--+-
Reporter: lilac |Owner:
Type: bug| Status: new
#3766: Parsing of lambdas is not consistent with Haskell'98 report.
-+--
Reporter: lilac | Owner:
Type: bug | Status: new
#3766: Parsing of lambdas is not consistent with Haskell'98 report.
--+-
Reporter: lilac | Owner:
Type: bug| Status: new
#3766: Parsing of lambdas is not consistent with Haskell'98 report.
--+-
Reporter: lilac | Owner:
Type: bug| Status: new
#3766: Parsing of lambdas is not consistent with Haskell'98 report.
--+-
Reporter: lilac | Owner:
Type: bug| Status: new
Today, as I was reading through The Haskell 98 Report (see
http://www.haskell.org/onlinereport/), I came across a minor typo, but
it seems that the only way to fix such typos is to report them on one
of the Haskell mailing lists; viz.:
The original committees ceased to exist when the original
On 6 Apr 2009, at 08:56, Benjamin L.Russell wrote:
Today, as I was reading through The Haskell 98 Report (see
http://www.haskell.org/onlinereport/), I came across a minor typo, but
it seems that the only way to fix such typos is to report them on one
of the Haskell mailing lists;
Thanks
... I hit Chapter 3 and started reading about expressions.
*If you are able to answer any of these questions, please send me an
email. I am very lost and confused in this section, so even one
answered question may help greatly.*
I actually decided to sit down and figure out the Haskell 98
answered question
may help greatly.*
I actually decided to sit down and figure out the Haskell 98 Report today.
Everything was going well until I began Chapter 3. Here's the section that
has me baffled:
In the syntax that follows, there are some families of nonterminals
indexed
On Fri, Aug 17, 2007 at 04:50:02AM -0700, Ian Duncan wrote:
So here's my list of questions so far:
1. What are nonterminals?
2. What are productions and substitutions?
[snip]
Sounds to me like you want a book on language design, grammars,
parsing, etc. :-)
There are many good ones out
Gentle Haskellers
It's pleasing that there have been so few bug reports about the Revised
Haskell 98 report, which was published in January 2003. But there have
been some: see
http://research.microsoft.com/~simonpj/haskell98-revised/haskell98-revis
ed-bugs.html
and every now and again
Folks
I am holding in my hands the first copy of the Haskell 98 Report to roll off the
presses at Cambridge University Press. It looks great. And it has a copyright
notice that says It is intended that this Report belong to the entire Haskell
community..., just as the online version does
is in the Haskell 98 Report itself, now begin printed. The definition
of lex is wrong.
Ah well, I knew this would happen. Id
better start keeping a new bug list!
Simon
-Original Message-
From: Jong Keun Na
[mailto:[EMAIL PROTECTED]]
Sent: 10 February 2003 02:48
To: Simon Peyton-Jones;
[EMAIL
Simon Peyton-Jones [EMAIL PROTECTED] writes:
Ah yes, this is a genuine bug. Haskell 98 changed at some point to
allow identifiers and field labels with a leading '_', but the library
didn't keep pace.
I believe the fix for 'lex' is something like the following.
Regards,
Malcolm
diff -u
Claus Reinke [EMAIL PROTECTED] writes:
So, as a small token, I've revised my original plan and will now buy one
of the printed versions (I shall also place higher priority on submitting
to JFP in the future;-). Let's support forward-looking publishers!
Thanks, Simon, and thanks, Conrad
Simon PJ writes:
the existing notice that says you can do what
you like with this Report will stay unchanged. No non-commercial
only caveats.
I remained relatively quiet throughout the discussion,
as I have not contributed to the Report, but I'm very
much relieved.
Scheme,
Folks,
As you know, Cambridge University Press are doing us the huge service of publishing
the Haskell 98 report, both as a special issue of the Journal of Functional
Programming (Jan 2003) and as a hardback book (it'll cost around £35).
I'm very, very, very happy to say that, following
:22 AM
Subject: The Haskell 98 Report
Folks,
As you know, Cambridge University Press are doing us the huge service of publishing
the Haskell 98
report, both as a special issue of the Journal of Functional Programming (Jan 2003)
and as a
hardback book (it'll cost around £35).
I'm very, very
[Resend, sorry for any duplicates you might get.]
On 20021129T102259-, Simon Peyton-Jones wrote:
The copyright will still be (c) Simon Peyton Jones (as it has for some
while; it has to be attached to someone or some thing),
AIUI, legally it is attached to everyone who has ever contributed
Ian Lynagh [EMAIL PROTECTED] writes:
I note with some sadness the more restrictive license that may be placed
on the Haskell 98 Report, as reported by the HCA.
I have a hard time imagining what this actually means. The report, as
it is licensed now allows for:
I have just grabbed a copy
On Tue, Nov 12, 2002 at 01:19:03AM +, Ian Lynagh wrote:
I note with some sadness the more restrictive license that may be placed
on the Haskell 98 Report, as reported by the HCA. The great
openness/freeness of haskell, both the report and implementations, is,
IMO, one of its most important
Simon Peyton-Jones [EMAIL PROTECTED] writes:
http://research.microsoft.com/~simonpj/h98-revised
404 Not Found.
Make that
http://research.microsoft.com/~simonpj/haskell98-revised
___
Haskell mailing list
[EMAIL PROTECTED]
I don't want to do that until its finished!
Which I earnestly hope will be soon.
Simon
| -Original Message-
| From: David Feuer [mailto:[EMAIL PROTECTED]]
| Sent: 20 February 2002 08:43
| To: [EMAIL PROTECTED]
| Subject: Haskell 98 Report
|
|
| Is the revised Haskell98 report going
| Just before Section D.1 there is the sentence
|
| When inferring the context for the derived instances, type
| synonyms must be expanded out first.
|
| I don't understand it. Which type synonyms need expansion?
Consider
type Foo a = [a]
data T a = MkT (Foo a) deriving( Eq
Simon Peyton-Jones wrote:
Feedback please...
One typo:
In the change for
Page 93, Appendix A, Standard Prelude
the comment should not talk about a fixtity declaration.
^
Bye
Christian Sievers
___
Haskell
the main things I've done this time is to
* revise yet again the wording about export lists
Two of the changes to Export Decls (Section 5.2) now conflict with
each other.
[Oct 2001]
The form `module M' abbreviates the set of all entities whose
unqualified name, e, is in scope, and
hello,
this was a bug in the report, the B import should not be qualified.
it has been fixed in the latest version of the report.
[Sept 2001]
For example
module A ( module B, C.f, g ) where -- an invalid module
import qualified B(f,g)
import qualified C(f)
" and "uniWhite".
5. [Re Christian S's proposal, which I sent
earlier, remove "opencom" from "lexeme"]
I think that does it. Pls confirm or
deny.
Simon
-Original Message-From: Memovich, Gary
[mailto:[EMAIL PROTECTED]] Sent: 19 July 2001
18:53
Simon Peyton-Jones proposed:
1. I will use lexeme consistently to mean what the lexeme
production means.
That's good.
2. The place that lexeme is currently used inconsistently is in 2.3
(Comments) Here I propose to replace paras 2 and 3 thus:
An ordinary comment begins with a
Wed, 25 Jul 2001 17:57:59 +0200 (MET DST), Christian Sievers [EMAIL PROTECTED]
pisze:
The sequence of dashes must not be followed by another symbol,
for example -- or --| do not begin a comment, they are just
ordinary lexemes.
Nor preceded. This is symmetrical, it's not dashes that start an
Mon, 23 Jul 2001 11:23:30 -0700, Mark P Jones [EMAIL PROTECTED] pisze:
I guess the intention here is that:
symbol - ascSymbol | uniSymbol_special | _ | : | | '
Right.
In fact, since all the characters in ascSymbol are either
punctuation or symbols in Unicode, the inclusion of
From: Dylan Thurston [EMAIL PROTECTED]
Date: Mon, 23 Jul 2001 19:57:54 -0400
On Mon, Jul 23, 2001 at 06:30:30AM -0700, Simon Peyton-Jones wrote:
Someone else, quoted by Simon, attribution elided by Dylan, wrote:
| 2.2. Identifiers can use small and large Unicode letters.
| What about
3. A precedence table says that case (rightwards) has higher
precedence
than operators and right associativity. If it's meaningful to talk
about precedence of such syntactic constructs as case at all,
it should
probably be told to have a lower precedence, so case x+1 of ...
is valid as
Marcin
Thanks for your careful read. Many of your suggestions I will
implement.
I'll send separate email about any others.
[Haskell mailing list folk: I hope you'll forgive email about the
minutae of the Haskell Report. But I don't want to let changes, or
even clarifications, go by without
Folks
Marcin is right about this. It is inconsistent as it stands.
I propose to delete the sentence The Preldue module
is always available as a qualified import... in the first
para of 5.6.1.
The situation will then be:
if you don't import Prelude explicitly, you implicitly get
| 3. A precedence table says that case (rightwards) has higher
| precedence than operators and right associativity. If it's
| meaningful to talk about precedence of such syntactic
| constructs as case at all, it should probably be told to have
| a lower precedence, so case x+1 of ... is valid
| 2.2. Identifiers can use small and large Unicode letters.
| What about caseless scripts where letters are neither small
| nor large? The description of module Char says: For the
| purposes of Haskell, any alphabetic character which is not
| lower case is treated as upper case (Unicode
Unfortunately both the old and the new situation are not so nice.
Both don't allow a simple translation of Haskell into the Haskell
kernel,
e.g. you cannot translate [1..] into Prelude.enumFrom 1, because the
latter may be ambiguous.
The following remark at the beginning of Section 3 is
Mon, 23 Jul 2001 15:11:32 +0100, Olaf Chitil [EMAIL PROTECTED] pisze:
Both don't allow a simple translation of Haskell into the Haskell
kernel,
e.g. you cannot translate [1..] into Prelude.enumFrom 1, because the
latter may be ambiguous.
That's why I was proposing that importing another
| Unfortunately both the old and the new situation are not so
| nice. Both don't allow a simple translation of Haskell into
| the Haskell kernel, e.g. you cannot translate [1..] into
| Prelude.enumFrom 1, because the latter may be ambiguous.
|
| The following remark at the beginning of
The report is vainly trying to say that, regardless of what is
lexically in scope, the builtin syntax refers to Prelude entities.
Perhaps I should reword the offending paragraph to say:
Free variables and constructors used in these translations
refer to entities defined by the
| 2.2. Identifiers can use small and large Unicode letters ...
If we're picking on the report's handling of Unicode, here's
another minor quibble to add to the list. In describing the
lexical syntax of operator symbols, the report uses:
varsym- (symbol {symbol | :})_reservedop
symbol
On Mon, Jul 23, 2001 at 06:30:30AM -0700, Simon Peyton-Jones wrote:
| 2.2. Identifiers can use small and large Unicode letters.
| What about caseless scripts where letters are neither small
| nor large? The description of module Char says: For the
| purposes of Haskell, any alphabetic
Simon Peyton-Jones wrote:
I've finished what I hope is the final version of the Haskell 98
Language and Library Reports
http://research.microsoft.com/~simonpj/haskell98-revised
haskell98-library-html/index.html still contains the following line:
title The Haskell Library Report 1.4
31 May 2001 16:10:43 -0600, Alastair David Reid [EMAIL PROTECTED] pisze:
and
if foo has type
foo :: (Ord a) = ty
then fooBy has type
fooBy :: (a - a - Bool) - ty
It's (a - a - Ordering) - ty, with the default value being
compare.
--
__( Marcin Kowalczyk * [EMAIL
| | deleteBy :: (a - b - Bool) - a - [b] - [b]
| |
| | I've found it usefully used at this more general type.
|
| Indeed, and
|
| deleteFirstsBy :: (a - b - Bool) - [b] - [a] - [b]
|
| and
|
| intersectBy :: (a - b - Bool) - [a] - [b] - [a]
Indeed.
We should either
]]
| Sent: 30 May 2001 18:42
| To: Simon Peyton-Jones
| Cc: [EMAIL PROTECTED]
| Subject: Re: Haskell 98 Report
|
|
| Hello Simon,
|
| Looking at the definition for deleteBy:
|
| deleteBy:: (x - a - Bool) - x - [a] - [a]
| deleteBy eq x []= []
| deleteBy eq x (y:ys
On 31-May-2001, Simon Peyton-Jones [EMAIL PROTECTED] wrote:
We should either generalise all three
deleteBy
deleteFirstsBy
intersectBy
or none.
In favour:
the more general types are occasionally useful
no programs stop working
Actually some programs will
On 31-May-2001, C.Reinke [EMAIL PROTECTED] wrote:
..it's easy enough for programmers who want a generalized version to just cut
and paste the code from the Haskell report and give it a more general type
signature,..
Fergus
Fergus Henderson [EMAIL PROTECTED] writes:
(It would be good for someone, perhaps Simon P-J., to keep a
list of issues like this which have been left out of Haskell 98
due to backwards compatibility concerns, so that they don't get
forgotten about when it comes to time for the next version.)
Simon Peyton-Jones wrote:
Folks
I've finished what I hope is the final version of the Haskell 98
Language and Library Reports
http://research.microsoft.com/~simonpj/haskell98-revised
However, experience shows that bug fixes are often themselves
buggy, so I urge you, once
| Sorry to get this comment in so late, but it is a small
| change. In the List module, the type signature for deleteBy
| is not as general as it could be, given the definition. It
| could be generalized to the following (no change to the definition):
|
| deleteBy :: (a - b - Bool) - a -
On Wed, May 30, 2001 at 09:46:53AM -0700, Simon Peyton-Jones wrote:
| Sorry to get this comment in so late, but it is a small
| change. In the List module, the type signature for deleteBy
| is not as general as it could be, given the definition. It
| could be generalized to the following
Hello Simon,
Looking at the definition for deleteBy:
deleteBy:: (x - a - Bool) - x - [a] - [a]
deleteBy eq x []= []
deleteBy eq x (y:ys)= if x `eq` y then ys else
y : deleteBy eq x ys
I can't help wondering why it isn't
| It could be generalized to the following (no change to the definition):
|
| deleteBy :: (a - b - Bool) - a - [b] - [b]
Indeed, and
deleteFirstsBy :: (a - b - Bool) - [b] - [a] - [b]
and
intersectBy :: (a - b - Bool) - [a] - [b] - [a]
Although curiously, its dual
Zhanyong Wan writes:
:
| I can't help wondering why it isn't
|
| deleteBy' :: (a - Bool) - [a] - [a]
| deleteBy' f [] = []
| deleteBy' f (y:ys) = if f y then ys else
| y : deleteBy' f ys
deleteBy'' f = filter (not . f)
Malcolm Wallace
Tom Pledger wrote:
Zhanyong Wan writes:
:
| I can't help wondering why it isn't
|
| deleteBy' :: (a - Bool) - [a] - [a]
| deleteBy' f [] = []
| deleteBy' f (y:ys) = if f y then ys else
| y : deleteBy' f ys
deleteBy'' f = filter
Zhanyong Wan writes:
| Tom Pledger wrote:
:
| deleteBy'' f = filter (not . f)
|
| No. deleteBy' f only deletes the *first* element that satisfies the
| predicate f, while filter (not . f) deletes *all* such elements.
Oops. Sorry. I ought to become less SQL-oriented...
Zhanyong Wan wrote:
Hello Simon,
Looking at the definition for deleteBy:
deleteBy:: (x - a - Bool) - x - [a] - [a]
deleteBy eq x []= []
deleteBy eq x (y:ys)= if x `eq` y then ys else
y : deleteBy eq x ys
I can't help
John
I'd like to update the Haskell 98 report to fix all the accumulated
typos. But before I do that I want to put the Report under CVS
somewhere. One possibility is to add it to the same repository
that holds GHC and Hugs (but as a separate CVS module of course).
That respository is already
60 matches
Mail list logo
