Marcin 'Qrczak' Kowalczyk wrote:
My preference is still (B). (A) is not *very* bad, but should really
replicate (-7) "foo" be []?
Mine too.
Actually after writing my own version of "drop" it turns out that
in my case n 0 is a programmer error and n length xs a user error.
So what you end up
The take-drop law I've always liked is
take n xs ++ drop n xs = xs, for all lists xs and all naturals n.
I agree that (take n _) and (drop n _) should both give errors for n 0.
On the other hand, I don't buy the argument that (take 1 []) should be
undefined because (head []) is
"Hamilton" == Hamilton Richards [EMAIL PROTECTED] writes:
Hamilton How about these definitions? They're like the Haskell98
Hamilton prelude definitions except that n0 is always an error,
Hamilton even if the list is [].
the problem with an unnecessary restriction is that it
Tue, 25 Jan 2000 14:41:54 -0800, Craig Dickson [EMAIL PROTECTED] pisze:
And I like having "head []" be an error, because if it returned
[], then it seems to me that that would have nasty implications
for pattern-matching.
head [] can't return anything than bottom because anything else has
Tue, 25 Jan 2000 15:33:25 -0800, Craig Dickson [EMAIL PROTECTED] pisze:
If "(x:xs)" does not match [], then the reason for this should be
that [] has no head to bind to x, nor tail to bind to xs;
No, the reason is simply that [] and (:) are distinct constructors.
E.g. the pattern Nothing
Wed, 26 Jan 2000 16:16:39 +0100 (MET), Ch. A. Herrmann
[EMAIL PROTECTED] pisze:
the problem with an unnecessary restriction is that it complicates
reasoning about the program.
Instead of
xs
= { take/drop-law }
take (n-m) xs ++ drop (n-m) xs
you have to write, e.g.:
xs
Many properties are broken anyway in presence of negative arguments
drop n . drop m = drop (n+m) -- try n = -1, m = 1
take n . drop m = drop m . take (n+m) -- try n = 1, m = -1
But following Simon assumption about collapsing integers to naturals,
you can
have
collapse n | n0 = 0
On Thursday, January 27, 2000 2:08 PM, Frank A. Christoph
[SMTP:[EMAIL PROTECTED]] wrote:
My preference is still (B). (A) is not *very* bad, but should really
replicate (-7) "foo" be []?
I could say: Sure, why not? replicate suffers from the same domain problem
as take/drop.
This was not
Brian Boutel wrote:
On Thursday, January 27, 2000 2:08 PM, Frank A. Christoph
[SMTP:[EMAIL PROTECTED]] wrote:
My preference is still (B). (A) is not *very* bad, but should really
replicate (-7) "foo" be []?
I could say: Sure, why not? replicate suffers from the same
domain problem
as
| Why not do what python does?
Thanks for an interesting suggestion, Alex!
However, we are in typo-fixing mode here. In the
interests of helping this discussion converge I'm
going to exercise my dictatorial powers. Though Alex's
suggestion has its attractions, I judge it too big a change
to
Chris Okasaki wrote:
For the people that share this sentiment, can you please
explain why ints that are too big should not similarly
give an error? I can see both being ok, or both being
errors. I just don't see why one should be ok and the
other an error.
IMHO, both should be errors.
On Tue, 25 Jan 2000, Chris Okasaki wrote:
I'm with the option (B): negatives are just outside
the domain of takedrop, and should give you an error
message.
For the people that share this sentiment, can you please
explain why ints that are too big should not similarly
give an error?
On Tue, 25 Jan 2000, D. Tweed wrote:
Oops, fixing two thinko's
f _ [] = []
f a xs =res:f a' zs
(ys,zs)=splitAt 40 xs
(a',res)=doStuff a ys
(My haskell coding is getting worse than my C++, which I didn't believe
possible...)
Phil Wadler writes:
| I'm with Jon Fairbairn on this. Negative arguments are an error
| because the domain of take and drop is the naturals. The problem
| is that we use Int to represent naturals. -- P
|
| For the people that share this sentiment, can you please
| explain why ints that are
I'm with Jon Fairbairn on this. Negative arguments are an error
because the domain of take and drop is the naturals. The problem
is that we use Int to represent naturals. -- P
Yep, this is exactly the same argument we had about this
a year or two ago, Phil. My attitude about the "implicit
Chris, I admit your argument about symmetry is attractive.
If you could put forward a concrete application, on a par with
the `break into blocks' application given earlier, you would
likely sway me. -- P
Chris Okasaki writes:
| But if the type *says* Int, then it should have reasonable behavior
| for ints. I look at the negative case as being equivalent to
| standard mathematical treatment of ranges such as i..j, where the
| range is considered to be empty if j i. Allowing take/drop to
|
(sorry, can't remember the original author)
| The correct definitions would be:
|
| take -2 -- drops the last 2 elements from the list
| (takes everything except the last 2 elements)
| drop -2 -- grabs the last 2 elements from the list
| (drops everything except
Tue, 25 Jan 2000 12:14:29 -0500 (EST), Chris Okasaki [EMAIL PROTECTED] pisze:
I would have no arguments with either approach, or with any other
approach that makes Nat explicit in the type.
But if the type *says* Int, then it should have reasonable behavior
for ints.
I can't agree with
On Wednesday, January 26, 2000 9:12 AM, Joe Fasel [SMTP:[EMAIL PROTECTED]] wrote:
The call some have made for the tightest possible error
checking also has merit, however. That would suggest
these definitions:
takeExactly 0 _ = []
takeExactly (n+1) (x:xs) = x : takeExactly n xs
Hi.
For H98, I prefer option (A). Option (B) gives an arbitrary
dissimilarity with rangeSize and enumFromTo. They currently match the
standard mathematical treatment of ranges such as i..j, which Chris
Okasaki mentioned. I'm not saying that they're sacred, just that a
shift to the style of
Brian Boutel [EMAIL PROTECTED] wrote:
We have seen various proposals about what laws should hold wrt
take and drop. I think there is a reasonable presumption that the
following very simple laws should hold first:
length (take n xs) === n
length (drop n xs) === length xs -n
Does that not
Tom Pledger [EMAIL PROTECTED] wrote:
Craig Dickson writes:
[...]
I don't want a pattern like "(x:xs)" to match the empty list, which
it presumably would if "head []" and "tail []" did not fail (x and
xs would both be bound to []).
I don't think it would. Patterns involve data
Chris Okasaki wrote:
I'm with the option (B): negatives are just outside
the domain of takedrop, and should give you an error
message.
For the people that share this sentiment, can you please
explain why ints that are too big should not similarly
give an error? I can see both being
On 25-Jan-2000, Craig Dickson [EMAIL PROTECTED] wrote:
Brian Boutel [EMAIL PROTECTED] wrote:
We have seen various proposals about what laws should hold wrt
take and drop. I think there is a reasonable presumption that the
following very simple laws should hold first:
length (take n
On 26-Jan-2000, Brian Boutel [EMAIL PROTECTED] wrote:
On Wednesday, January 26, 2000 1:52 PM, Fergus Henderson
[SMTP:[EMAIL PROTECTED]] wrote:
I agree that it is too big a change for Haskell 98.
But I think it would be too big a change for Haskell 2000 too.
Making a change like that
Simon Peyton-Jones [EMAIL PROTECTED]
announces the editor's proposals for the "typos" fix in Haskell-98.
Partition
[..]
The "standard" (lazier) defn should be the one in the H98 report.
PROPOSAL: use the filter/filter defn of partition
I agree.
Take and drop
[..]
I can see three
Take and drop
[..]
I can see three alternatives:
(A) Make them defined for any n. If n 0, do something reasonable:
take: give empty list
drop: give whole list
(B) Make them defined for n length xs, but fail for n 0.
(C) Status quo
PROPOSAL: Use alternative (A)
Why not do what python does?
drop -2 -- drops the last 2 elements from the list
take -2 -- grabs the last 2 elements from the list
take n list | n0 = drop (length list + n) list
drop n list | n0 = take (length list + n) list
If the list is an infinite list, the behavior is equivalent to B.
If
On Tuesday, January 25, 2000 8:38 AM, S. Alexander Jacobson [SMTP:[EMAIL PROTECTED]] wrote:
Why not do what python does?
drop -2 -- drops the last 2 elements from the list
take -2 -- grabs the last 2 elements from the list
take n list | n0 = drop (length list +
Ok. so I got it backward. The functionality is still useful and belongs
with take and drop.
The correct definitions would be:
take -2 -- drops the last 2 elements from the list
(takes everything except the last 2 elements)
drop -2 -- grabs the last 2 elements from the list
S. Alexander Jacobson writes:
The correct definitions would be:
take -2 -- drops the last 2 elements from the list
(takes everything except the last 2 elements)
drop -2 -- grabs the last 2 elements from the list
(drops everything except the last 2 elements)
Brian Boutel wrote:
take -2 [1,2,3,4] ++ drop -2 [1,2,3,4] - [3,4,1,2]
But [1,2,3,4] is NOT the same as [3,4,1,2]. So the equality doesn't hold.
Personally, for reasons I'm not sure I can articulate, I've always strongly
disliked the notion that negative arguments should produce "backwards"
anuary 2000 02:39 pm
Subject: Re: fixing typos in Haskell-98
Brian Boutel wrote:
take -2 [1,2,3,4] ++ drop -2 [1,2,3,4] - [3,4,1,2]
But [1,2,3,4] is NOT the same as [3,4,1,2]. So the equality doesn't hold.
Personally, for reasons I'm not sure I can articulate, I've always
strongly
Mon, 24 Jan 2000 07:49:30 -0800, Simon Peyton-Jones [EMAIL PROTECTED] pisze:
(A) Make them defined for any n. If n 0, do something reasonable:
take: give empty list
drop: give whole list
(B) Make them defined for n length xs, but fail for n 0.
I vote for (B) or
All the proposals break this law as well, so I this argument is weak (if
not insane :-))
-Alex-
IMHO, a consistency is the most important rule here.
I do not have any problems with any of those proposals,
providing that I can apply similar reasoning to other
]
Subject: Re: drop take [was: fixing typos in Haskell-98]
IMHO, that would be the _insane_ definitions :-) Firstly, nothing
suggests to me that rationale of such behaviour.
The rationale is:
1. these are useful functions
2. if this is insane, so is python. The correspond
Simon Peyton-Jones [EMAIL PROTECTED] wrote:
(A) Make them defined for any n. If n 0, do something reasonable:
take: give empty list
drop: give whole list
(B) Make them defined for n length xs, but fail for n 0.
I vote for (B).
'Qrczak' Kowalczyk [EMAIL
"S. Alexander Jacobson" wrote:
The python behavior is:
take n list | length list + n 0 = []
drop n list | length list + n 0 = list
I think this is the correct complement (dual?) of:
take n list | length list - n 0 = list
drop n list | lenght list - n 0
39 matches
Mail list logo
