On Wed, Sep 25, 2002 at 12:34:53PM +0100, Simon Peyton-Jones wrote:
I spoke too soon. Consider
data F = F Int !Int
data S = S { x::Int, y::!Int }
According to the words above
F {} is illegal
but what about this one?
S {}
I think the sentence in question (end of 3.15.2)
| I think the sentence in question (end of 3.15.2) is just a
clarification;
| the preceding 4 rules are sufficient and clear: F{}, S{} and S{x=3}
are
| all illegal because they omit a value for a strict field. That is,
it's
| correct, though not strictly necessary, nor does it cover all the
Blargh. Excellent point. I had totally forgotten that. I withdraw all
suggested changes except a cross-ref to the section you mention. Sigh.
My brain is getting soft.
Actually the rules referenced appear immediately above, so no reference is
necessary.
My original message was not
On Wed, Sep 25, 2002 at 12:34:53PM +0100, Simon Peyton-Jones wrote:
I spoke too soon. Consider
data F = F Int !Int
data S = S { x::Int, y::!Int }
According to the words above
F {} is illegal
but what about this one?
S {}
I think the sentence in question (end of 3.15.2)
| I think the sentence in question (end of 3.15.2) is just a
clarification;
| the preceding 4 rules are sufficient and clear: F{}, S{} and S{x=3}
are
| all illegal because they omit a value for a strict field. That is,
it's
| correct, though not strictly necessary, nor does it cover all the
On the matter of echoing, in Section 7.1 there seem to be two
possibilities:
1. Delete the sentence By default, these input functions echo to
standard output. altogether.
2. Replace the sentence by
If the standard input (stdin) is a terminal device,
any input on stdin is
Glynn writes:
| 2. Regarding the buffering issue, I suggest adding something along the
| lines of the following to section 11.4.2 of the library report:
|
| For a stream which is associated with a terminal device, setting the
| mode to no-buffering will also disable any line-buffering which
Dylan Thurston [EMAIL PROTECTED] wrote,
On Thu, Sep 19, 2002 at 02:36:01PM +0100, Simon Peyton-Jones wrote:
The copyright notice is, I believe, agreed with CUP, but I must check
that. The online versions will remain available.
Will the online version be available with the current
Simon Peyton-Jones wrote:
Thanks for your input. If you think it is important, could you please
propose one or more concrete changes to the wording of the Language
Report or the Library Report or both. Then we'll get a better idea of
what you have in mind. (Start from the current draft
Peyton-Jones
| Cc: [EMAIL PROTECTED]
| Subject: RE: Haskell 98: Behaviour of hClose
|
|
| Simon Peyton-Jones wrote:
|
|
| | 2. Is there actually anything special about the treatment of
stdin, or
| | does this apply to any input stream which is associated with a
| | terminal?
|
| I'm
On Thu, Sep 19, 2002 at 02:36:01PM +0100, Simon Peyton-Jones wrote:
The copyright notice is, I believe, agreed with CUP, but I must check
that. The online versions will remain available.
Will the online version be available with the current copyright, or
will it only be available with the
| contributions. So the book currently shows me as editor, while the
| preface attempts to give credit where credit is due. Please help me
to
| improve it.
|
| You don't specify very clearly when someone deserves to be on the
| contribution list.
|
| I reported some errors in the report
| No yelling, but some random points for consideration:
|
| 1. It might be worth being more explicit, i.e. stating whether this is
| because the runtime explicitly enables echoing, or because it's
| assumed that echoing will already be enabled.
Well, at Haskell user doesn't care. It's
Simon Peyton-Jones [EMAIL PROTECTED] writes:
(You can change echoing settings via the IO.hSetEcho etc.)
Ahem, one of the deficiencies of Haskell'98 is that there is no function
IO.hSetEcho. There used to be one in Haskell 1.3 I think, so I guess there
was a good reason for removing it?
On Wed, Sep 18, 2002 at 09:21:02AM +0100, Simon Peyton-Jones wrote:
| No yelling, but some random points for consideration:
|
| 1. It might be worth being more explicit, i.e. stating whether this is
| because the runtime explicitly enables echoing, or because it's
| assumed that echoing
| -Original Message-
| From: Ferenc Wagner [mailto:[EMAIL PROTECTED]]
| Sent: 18 September 2002 11:50
| To: [EMAIL PROTECTED]
| Subject: Re: Haskell 98: Behaviour of hClose
|
| Ross Paterson [EMAIL PROTECTED] writes:
|
| So I favour deletion of the offending sentence, leaving
Ahem how true. I have not idea why it was removed. But I can't put
anything back in at this stage.
Simon
| -Original Message-
| From: Malcolm Wallace [mailto:[EMAIL PROTECTED]]
| Sent: 18 September 2002 10:04
| To: Simon Peyton-Jones
| Cc: [EMAIL PROTECTED]
| Subject: Re: Haskell 98
Simon Peyton-Jones [EMAIL PROTECTED] writes:
What I intended was
a simple interactive Haskell program should behave the same
on any OS/environment
What you and Ross seem to be saying is
no, the behaviour of the program can, and should, depend
on the
Simon Peyton-Jones [EMAIL PROTECTED] writes:
If that's the consensus I'll happily leave echoing
behaviour unspecified. Remember, that means that a
conforming implementation can do whatever it pleases, and
hence it's impossible to write a portable interactive
Haskell program. Is that you
On Wed, 18 Sep 2002, Simon Peyton-Jones wrote:
What I intended was
a simple interactive Haskell program should behave the same
on any OS/environment
What you and Ross seem to be saying is
no, the behaviour of the program can, and should, depend
on the
Simon Peyton-Jones wrote:
What I intended was
a simple interactive Haskell program should behave the same
on any OS/environment
What you and Ross seem to be saying is
no, the behaviour of the program can, and should, depend
on the OS/environment
If that's
Simon Peyton-Jones wrote:
| 2. Is there actually anything special about the treatment of stdin, or
| does this apply to any input stream which is associated with a
| terminal?
I'm proposing just stdin. My motivation is to make simple stupid
programs work right.
Argh. Too much of this
Sigbjorn writes:
| Re: your request to have a final look through the report
| for any wibbles that might remain -- Section 11.3.2 of the
| lib report isn't clear on what the expected behaviour of
| (hClose h hClose h) ought to be, i.e., will the second
| hClose fail or not?
|
| Both GHC and
Simon Peyton-Jones wrote:
| Re: your request to have a final look through the report
| for any wibbles that might remain -- Section 11.3.2 of the
| lib report isn't clear on what the expected behaviour of
| (hClose h hClose h) ought to be, i.e., will the second
| hClose fail or not?
|
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
. Diatchki [mailto:[EMAIL PROTECTED]]
| Sent: 04 December 2001 18:41
| To: [EMAIL PROTECTED]
| Subject: Re: Haskell 98 Revised
|
|
| hello,
|
| it seems that if the qualified names in instance declarations
| are removed, the qualified methods (data constructors) in
| exports ought to be removed
Folks,
Concerning the recent change about instance declarations, should
this be valid?
module M( C(op1) ) where-- NB: op2 not exported
class C a where
op1 :: a-a
op2 :: a-a
module N where
import M
instance C
Hi!
For whatever that is worth, my semantics agrees with Simon's point here,
ie in the example code
module M( C(op1) ) where-- NB: op2 not exported
class C a where
op1 :: a-a
op2 :: a-a
module N where
import M
hello,
it seems that if the qualified names in instance declarations are removed,
the qualified methods (data constructors) in exports ought to be removed as
well. example: currently in Haskell one may write
module M ( P.C(Q.f) ) where
import qualified P
import qualified Q
...
qualifying the
|
http://research.microsoft.com/~simonpj/haskell98-revised/haskell98-repor
t-html/index.html
| says Revised: October 2001 - am I seeing the latest version?
Yes you are -- my mistake.
| You still have
| lexeme - ... | qop | ...
| in the lexical syntax but have
| qop - qvarop | qconop
|
Hi Simon
It's that time of the month. I'm putting out the November release
of the Revised Haskell 98 Report. As ever, I earnestly seek your
feedback.
In appendix B (syntax), B.3 (layout) says
* A stream of tokens as specified by the lexical syntax in the Haskell
report, with the
On Fri, Nov 02, 2001 at 09:30:36AM -0800, Simon Peyton-Jones wrote:
Haskellers!
Hi Simon :-)
It's that time of the month. I'm putting out the November release
of the Revised Haskell 98 Report. As ever, I earnestly seek your
feedback. Especially I'd like to know whether I have stumbled
George Russell [EMAIL PROTECTED] writes:
In addition, I suggest that, since it is widely agreed that the instances of
Enum for Float and Double
And (Ratio a)?
are highly unsatisfactory
-kzm
--
If I haven't seen further, it is by standing in the footprints of
Ketil Malde wrote:
George Russell [EMAIL PROTECTED] writes:
In addition, I suggest that, since it is widely agreed that the instances of
Enum for Float and Double
And (Ratio a)?
Yes, you've got a point there. They'd none of 'em be missed.
Of course mathematicians are well aware that
| In addition, I suggest that, since it is widely agreed that
| the instances of Enum for Float and Double are highly
| unsatisfactory, the report should give these instances the
| same status as n+k patterns have (in 1.4 of the recent
| revision). In particular, their use should be
| Somebody raised the issue why to/fromEnum doesn't use Integer
| instead of Int. This would, it would seem, solve at least
| some of the Enum problems that arise from (integral) types
| with more than 4G values. So, again, why not?
There was an extended discussion on this point, I believe,
Simon Peyton-Jones wrote:
[snip]
The Revised Haskell 98 report is suppposed to be in
conclusion mode. An attempt to decide what features are
deprecated would open up a big new debate. One could
instead list features which are controversial --- that would
be easier. Whether it would
On Wed, Oct 24, 2001 at 07:51:12AM -0700, Simon Peyton-Jones wrote:
The Report is (regrettably) silent about what the Integer
instances for succ and pred should be, but they should definitely simply
add 1 (resp subtract 1). They should emphatically not use the default
methods. I will add
| | (Actually, ghc is `wrong': hbc, hugs and nhc98 match the Report's
| | specification here: succ = toEnum . (+1) . fromEnum
| | This is confirmed by the description of the semantics in
| | section 3.10.)
|
| Lies, all lies. The default methods do not constitute a specification;
| in this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
How about making default method for asin
asin x = atan(x/sqrt(1-x^2))
Can't be worse than the default for (**) ;-)
- --
Russell O'Connor[EMAIL PROTECTED]
http://www.math.berkeley.edu/~roconnor/
``This is not a
[EMAIL PROTECTED] wrote:
How about making default method for asin
asin x = atan(x/sqrt(1-x^2))
Can't be worse than the default for (**) ;-)
Oh, it can. As well as its own problems when x is close to 1, it
inherits, through the default definition of sqrt, the problems of (**)
when x
An apparently-innocuous suggestion about adding default methods for
sinh and cosh led to a flood of mail. Since no consensus emerged, I
plan to leave things as they are in the Haskell 98 Report. Namely,
the following default methods for the Floating class are there:
x**y = exp (log x
On Tuesday 16 October 2001 07:29, Fergus Henderson wrote:
[...]
The whole idea of letting you omit method definitions for methods with
no default and having calls to such methods be run-time errors is IMHO
exceedingly odd in a supposedly strongly typed language, and IMHO ought
to be
On Tuesday 16 October 2001 07:29, Fergus Henderson wrote:
[...]
The whole idea of letting you omit method definitions for methods with
no default and having calls to such methods be run-time errors is IMHO
exceedingly odd in a supposedly strongly typed language, and IMHO ought
to be
Hi!
Jon Fairbairn wrote:
I agree too, but being able to omit method definitions is
sometimes useful -- would it be possible to make calls to
those methods a /static/ error? I suspect this would be hard
to do.
Yes, quite tricky. The problem is that the class constraints (in an
inference
Thu, 18 Oct 2001 13:49:11 +0200, Karl-Filip Faxen [EMAIL PROTECTED] pisze:
There are two solutions that I can see: Annotate classes in class
constraints with exactly which methods were used. Thus for the
expression x+y the inference algorithm would record the constraint
Num{+} a if x and y
Tue, 16 Oct 2001 15:29:36 +1000, Fergus Henderson [EMAIL PROTECTED] pisze:
Not giving a default definition is *not* the same as giving a default
definition that calls error. It's significantly safer. The difference
is that the former makes it much easier for compilers to issue warnings
Fpr the Revised Haskell 98 report, Russell O'Connor suggests:
| Also, I understand you are reluctant to make library changes,
| but sinh and cosh can easily be defined in terms of exp
|
| sinh x = (exp(x) - exp(-x))/2
| cosh x = (exp(x) + exp(-x))/2
|
| (source: Calculus Third
Simon Peyton-Jones:
Russell O'Connor suggests:
| but sinh and cosh can easily be defined in terms of exp
|
| sinh x = (exp(x) - exp(-x))/2
| cosh x = (exp(x) + exp(-x))/2
| I suggest removing sinh and cosh from the minimal complete
| definition, and add the above defaults.
This
2. So, they hold for the Complex numbers as well. The gymnastics with
complex sinh and cosh seems to be redundant.
Well, I would be a little careful changing these. Some of the definitions
in numerical part of the Prelude look more convoluted than they need to
be, but it's because they have
| sinh x = (exp(x) - exp(-x))/2
| cosh x = (exp(x) + exp(-x))/2
...
This looks pretty reasonable to me. We should have default methods
for anything we can.
Why not provide defaults for the inverse functions as well?
asinh x = log (x + sqrt (1+x*x))
acosh x = log (x + (x+1) * sqrt
- Original Message -
From: Jerzy Karczmarczuk [EMAIL PROTECTED]
...
Simon Peyton-Jones:
Russell O'Connor suggests:
| but sinh and cosh can easily be defined in terms of exp
|
| sinh x = (exp(x) - exp(-x))/2
| cosh x = (exp(x) + exp(-x))/2
| I suggest removing sinh
| 1. Actually, I wouldn't even call that default
| definitions. These ARE
| definitions of sinh and cosh.
|
| Mathematically, yes. Numerically, no. Even if 'exp' is
| implemented with high accuracy, the suggested defaults may
| return a very inaccurate (in ulps) result. Take sinh near
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 15 Oct 2001, Lennart Augustsson wrote:
Why not provide defaults for the inverse functions as well?
asinh x = log (x + sqrt (1+x*x))
acosh x = log (x + (x+1) * sqrt ((x-1)/(x+1)))
atanh x = log ((x+1) / sqrt (1 - x*x))
That's a good idea too.
Is there a reason for defining acosh as above instead of
acosh x = log(x + sqrt(x*x-1))
If there is one I can't remember it. :-)
-- Lennart
___
Haskell mailing list
[EMAIL PROTECTED]
Simon PJ wrote:
Fpr the Revised Haskell 98 report, Russell O'Connor suggests:
=20
| Also, I understand you are reluctant to make library changes,=20
| but sinh and cosh can easily be defined in terms of exp
|=20
| sinh x =3D (exp(x) - exp(-x))/2
| cosh x =3D (exp(x) +
On Mon, Oct 15, 2001 at 06:27:52PM +0200, George Russell wrote:
Simon PJ wrote:
Fpr the Revised Haskell 98 report, Russell O'Connor suggests:
=20
| Also, I understand you are reluctant to make library changes,=20
| but sinh and cosh can easily be defined in terms of exp
Dylan Thurston wrote:
[snip]
No. As has been pointed out, this is a bad idea numerically because
it will give the wrong answer for sinh x for very small values of
x. As a matter of fact, you will also get the wrong answer for very large
values of x, where exp(x) can overflow even though
On 15-Oct-2001, Simon Peyton-Jones [EMAIL PROTECTED] wrote:
The proposal is only to give default declarations
in the class defn for sinh, cosh, and perhaps as Lennart suggests
asinh, acosh, atanh. They give a reasonable first cut if you
don't write definitions yourself. But you can
On Mon, Oct 15, 2001 at 03:52:06PM +0200, Kent Karlsson wrote:
Simon Peyton-Jones:
Russell O'Connor suggests:
| but sinh and cosh can easily be defined in terms of exp
| sinh x = (exp(x) - exp(-x))/2
| cosh x = (exp(x) + exp(-x))/2
...
This looks pretty reasonable to me. We
In general, this is why LIA-2 (Language Independent Arithmetic, part
2, Elementary numerical functions, ISO/IEC 10967-2:2001) [. . .]
This sounds like a very interesting standard. I am constantly annoyed
by ISO's attempts to hide their standards; one might wonder what the
purpose is of
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
Marcin writes:
| The Haskell 98 Report says that fail in instance Monad IO invokes error.
| The Library Report says that fail in instance Monad IO raises a user
error.
|
| I would let it raise a user error, to be able to use fail in exception
| monads where strings suffice as the error type.
1. Marcin Kowalczyk pointed out that scanl1 and
scanr1 fail on empty args, whereas they could perfectly well
return [] on such arguments.
Does the same apply for foldl1 and foldr1?
Regards,
Malcolm
On 15-Mar-2000, Malcolm Wallace [EMAIL PROTECTED] wrote:
1. Marcin Kowalczyk pointed out that scanl1 and
scanr1 fail on empty args, whereas they could perfectly well
return [] on such arguments.
Does the same apply for foldl1 and foldr1?
No, returning [] from foldl1 and foldr1 would
3. Manuel points out
I must say that I'm strongly tempted to disallow empty qualifiers
and make n=1. I'm not sure how this change crept in in the first
place. Does anyone care? Urgle.
The report is in a bit of a mess here.
The top of section 3 (the summary of exp syntax) also has n=1.
| * Opinion seems pretty evenly balanced between
| (A) Accept negative arg (take yields [], drop yields xs)
| (B) Fail on negative arg
I've counted up votes. I was right about it being
evenly balanced. I count 9 people in favour of (A) and 9 in
favour of (B), not counting me.
If
1 - 100 of 152 matches
Mail list logo
