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
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
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
> 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.
But instead I will point out that you don't need to define replicate via
take, so, in principal, that beha
> 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 | n<0
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.:
>
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
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 ha
> "Hamilton" == Hamilton Richards <[EMAIL PROTECTED]> writes:
Hamilton> How about these definitions? They're like the Haskell98
Hamilton> prelude definitions except that n<0 is always an error,
Hamilton> even if the list is [].
the problem with an unnecessary restriction is that
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 undefi
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 l
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 could cause previously working programs
> to fail, with no
On 25-Jan-2000, Chris Okasaki <[EMAIL PROTECTED]> wrote:
> -- provide a simple type synonym
> type Nat = Int
> along with a prominent comment that any function that
> *says* Nat in its type should raise an error on a negative argument
That sounds to me like good programming s
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:
> >
> >
Chris Okasaki wrote:
>
> > I'm with the option (B): negatives are just outside
> > the domain of take&drop, 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
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 invo
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 th
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 opt
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
Tue, 25 Jan 2000 09:51:15 -0500, Chris Okasaki <[EMAIL PROTECTED]> pisze:
> 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 an
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 w
(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 ex
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
| handl
"Pablo E. Martinez Lopez" wrote:
> No. If I want you to put a coin on the table, I will certainly not say:
> "Take -1 coins from the table"!
True, one ought to say "drop -1 coin from the table" => "let me view the
coins on the table, but hide -1 of them" => "show one of the previously
hidden ones
| 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)
|
| drop n list | n<0 = drop
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
> 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 "implic
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
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...)
___cheers,_dave___
On Tue, 25 Jan 2000, Chris Okasaki wrote:
> > I'm with the option (B): negatives are just outside
> > the domain of take&drop, 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
> > I'm with the option (B): negatives are just outside
> > the domain of take&drop, 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 ok, or both b
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 too big should not similarly
>
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
:51
To: [EMAIL PROTECTED]
Subject: Re: drop & take [was: fixing typos in Haskell-98]
> I'm with the option (B): negatives are just outside
> the domain of take&drop, and should give you an error
> message.
For the people that share this sentiment, can you please
explain why
> I'm with the option (B): negatives are just outside
> the domain of take&drop, 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 ok, or both being
errors.
> I think negative take/drop should be conceptually viewed as
> prepending/appending "empty"/"bottom"/"default value". It would be nice
> if "take 5 (take -1 some_list)" was equal to "take 4 some_list". (I
> guess it would be more difficult to achieve this with the opposite
> order.)
No. If I wan
This is probably flame bait. You are warned!
Simon Peyton-Jones 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've heard suppp
| 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
"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 lis
> 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' Kowal
S. Alexander Jacobson Shop.Com
1-212-697-0184 voiceThe Easiest Way To Shop
> > -Original Message-
> > From: S. Alexander Jacobson [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, January 25, 2000 10:16 AM
> > To:
Thorn
> Cc: [EMAIL PROTECTED]
> 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 f
> 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
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 (
> 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 corresponding python is:
def take list n: return list[:n]
def drop lis
[EMAIL PROTECTED]>
Sent: Monday, 24 January 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.
>
>
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"
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 eleme
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
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 | n<0 = drop (length list +
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 | n<0 = drop (length list + n) list
drop n list | n<0 = take (length list + n) list
If the list is an infinite list, the behavior is equivalent to B.
If
> 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 al
> > 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
> >
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
54 matches
Mail list logo
