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
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 ve
"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, Con
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.
S
[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
gt;; "Conrad Guettler (Conrad Guettler
(CUP))"
<[EMAIL PROTECTED]>
Sent: Friday, November 29, 2002 10: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 Jo
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,
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 HC&A. The great
> openness/freeness of haskell, both the report and implementations, is,
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 HC&A.
I have a hard time imagining what this actually means. The report, as
it is licensed now allows for
Ian Lynagh wrote:
Hi all,
I note with some sadness the more restrictive license that may be placed
on the "Haskell 98 Report", as reported by the HC&A. The great
openness/freeness of haskell, both the report and implementations, is,
IMO, one of its most important features.
I hav
Hi all,
I note with some sadness the more restrictive license that may be placed
on the "Haskell 98 Report", as reported by the HC&A. The great
openness/freeness of haskell, both the report and implementations, is,
IMO, one of its most important features.
I have just grabbed
Folks
I'm happy to say that the Haskell 98 Report (both language and
libraries) is going to be published as a book! It'll be a (very)
special issue of the Journal of Functional programming (Jan 2003),
but will be available separately through bookshops as a book
published by
"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]
http://www.haskel
Folks,
I've finally managed to push out the May 2002 release of
the Haskell 98 report.
http://research.microsoft.com/~simonpj/h98-revised
As far as I know there are no outstanding issues, so I hope
that there will be blissful silence for a month and I can freeze it.
I'd ha
Folks
Before I get buried in ICFP submissions I thought I should
get out the H98 report draft.
It's in the usual place:
http://research.microsoft.com/~simonpj/haskell98-revised
Main changes since the Dec release are:
Much improved informal semantics of pattern matching (3.17).
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
Is the revised Haskell98 report going to be put in its proper place on
the web site any time soon? As it is, it is sitting off to the side
while the old Report sits in the seat of honor.
David Feuer
___
Haskell mailing list
[EMAIL PROTECTED]
http://www
| 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 )
hen I thought and doesn't encourage me to
implement it. Naturally all this is pure guesswork, because the Haskell
98 report doesn't explain anything of this...
Olaf
--
OLAF CHITIL,
Dept. of Computer Science, The University of York, York YO10 5DD, UK.
URL: http://www.cs.york.ac.uk
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? All the u_n
are type variables.
Besides, this would make deriving even more horrible than it i
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
___
Haske
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
> 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
It's that time of the month! Another iteration of the Revised Haskell
98 Report!
http://research.microsoft.com/~simonpj/haskell98-revised
I'm happy to say that my orbit is diminishing in radius and I
shall shortly turn into a black hole.
Seriously, the main things I've
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 sta
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 wi
the production for "ANY" should
include "return", "linefeed" 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
> 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.
> > |
Mon, 23 Jul 2001 11:23:30 -0700, Mark P Jones <[EMAIL PROTECTED]> pisze:
> I guess the intention here is that:
>
> symbol -> ascSymbol | uniSymbol_
Right.
> In fact, since all the characters in ascSymbol are either
> punctuation or symbols in Unicode, the inclusion of ascSymbol
> is redunda
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
| 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 | :})_
symbol-> asc
> 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
| 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
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 anothe
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 misleadi
| 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 actua
| 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 vali
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
im
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 gi
> 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 v
0.4.1. "http:://haskell.org" - typo. Same in the Library Report.
2.2. "any UNIcode character" - spelling inconsistent with "Unicode"
elsewhere. Same in appendix B.
2.2. Identifiers can use small and large Unicode letters. What about
caseless scripts where letters are neither small nor large? The
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:
The Haskell Library Report 1.4
B
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 K
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 vers
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,.."
>
>
So much for my small, innocuous, non controversial suggestion :-).
Fergus Henderson wrote:
>
> On 31-May-2001, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> > We should either generalise all three
> > deleteBy
> > deleteFirstsBy
> > intersectBy
> > or none.
> >
> > In favour:
"..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 Henderson, June 2001
Is this definition of reuse in Hask
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 progra
EMAIL PROTECTED]]
| 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 :: (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
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
>
>
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...
_
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
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
> > | 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
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
del
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 followi
| 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 -
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, on
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 again, to take a look at your favourite
p
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 al
The Haskell 98 Report has (in 3.14):
exp -> do { stmts } (do expression)
stmts -> stmt1 ; ... ; stmtn (n>=0)
stmt -> exp
| pat <- exp
| let decls
| (empty statment)
which allows the following:
do {}
do {let x = 5
Message-
> From: Ross Paterson
> Sent: Monday, July 26, 1999 10:27 AM
> To: [EMAIL PROTECTED]
> Subject: Haskell 98 Report: do expression syntax
>
>
> The Haskell 98 Report has (in 3.14):
>
> exp -> do { stmts } (do expression)
> stmts ->
63 matches
Mail list logo
