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)
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
35 matches
Mail list logo
