Neil Mitchell wrote:
Hi
A more serious point is that in some cases we might want take to
underapproximate, or zip to truncate (or tail [] = [] ?). I don't
think there's
always a clear library choice here.
I have a zipWithEq function I often use, which crashes if the zip'd
lists aren't equal.
Hi
Although I appluad the semantics of the safe package, I'm not delighted
with the idea of replacing our concise elegant standard library names
with uglyAndRatherLongCamelCaseNamesThatCouldBePerlOrEvenJava though.
Conciseness of expression is a virtue.
They aren't that long - merely an
Neil Mitchell wrote:
Hi
Although I appluad the semantics of the safe package, I'm not delighted
with the idea of replacing our concise elegant standard library names
with uglyAndRatherLongCamelCaseNamesThatCouldBePerlOrEvenJava though.
Conciseness of expression is a virtue.
They aren't that
On Thu, 2007-09-13 at 09:56 +0100, Jules Bean wrote:
Neil Mitchell wrote:
Hi
Although I appluad the semantics of the safe package, I'm not delighted
with the idea of replacing our concise elegant standard library names
with uglyAndRatherLongCamelCaseNamesThatCouldBePerlOrEvenJava
Hi
Similarly, I expect foo and foo' to be equivalent, except for strictness
properties, but perhaps an underscore could be used for slightly
different behaviors (interpretations, as it were)? tail_ or zip_,
anyone?
There are 4 variants of tail:
tail :: [a] - [a] -- normal
tailDef :: [a] -
Hello,
There are 4 variants of tail:
tail :: [a] - [a] -- normal
tailDef :: [a] - [a] - [a] -- returns the first argument on []
tailMay :: [a] - Maybe [a] -- returns a Nothing
tailNote :: String - [a] - [a] -- crashes, but with a helpful message
tailSafe :: [a] - [a] -- returns [] on []
Hi
Is there a reason for not having
tailM :: Monad m = [a] - m [a]
which, at least for me, is much more useful?
No, that probably is a much more sensible choice. Patches welcome :)
Thanks
Neil
___
Haskell-Cafe mailing list
* Neil Mitchell wrote:
There are 4 variants of tail:
tail :: [a] - [a] -- normal
tailDef :: [a] - [a] - [a] -- returns the first argument on []
tailMay :: [a] - Maybe [a] -- returns a Nothing
tailNote :: String - [a] - [a] -- crashes, but with a helpful message
tailSafe :: [a] - [a] --
Hi
From the logical point of view tailMay is the right one.
It pushes the error handling to the caller programm.
tail = fromJust . tailMay
The error messages suffer:
tail [] = error: fromJust Nothing
That's why I supplied tailNote, where tailNote foo broke its
invariant! [] gives the
Jeff Polakow wrote:
Hello,
There are 4 variants of tail:
tail :: [a] - [a] -- normal
tailDef :: [a] - [a] - [a] -- returns the first argument on []
tailMay :: [a] - Maybe [a] -- returns a Nothing
tailNote :: String - [a] - [a] -- crashes, but with a helpful message
tailSafe ::
On Thu, 2007-09-13 at 13:56 +0100, Neil Mitchell wrote:
tail = fromJust . tailMay
The error messages suffer [..]
That's why I supplied tailNote
Still, given tailMay, we have:
tailDef xs = maybe xs id . tailMay
tailNote msg = tailDef (error msg)
tailSafe = tailDef []
tail =
Jules Bean wrote:
I'm not delighted with the idea of replacing our concise elegant
standard library names with
uglyAndRatherLongCamelCaseNamesThatCouldBePerlOrEvenJava though.
Conciseness of expression is a virtue.
I, on the other hand, I'm not delighted with names such as Eq and
Ord.
Conor McBride wrote:
Hi folks
On 12 Sep 2007, at 00:38, Brent Yorgey wrote:
On 9/11/07, PR Stanley [EMAIL PROTECTED] wrote: Hi
take 1000 [1..3] still yields [1,2,3]
I thought it was supposed to return an error.
[..]
If for some reason you want a version that does return an error in
Hi
On 12 Sep 2007, at 11:44, ChrisK wrote:
Conor McBride wrote:
I'd like operations to complain
about bogus input, rather than producing bogus output.
Then you want a runtime assertion checking error helpful Data.List
replacement.
Could you use Control.Exception.assert and make a
Hi
A more serious point is that in some cases we might want take to
underapproximate, or zip to truncate (or tail [] = [] ?). I don't
think there's
always a clear library choice here.
I have a zipWithEq function I often use, which crashes if the zip'd
lists aren't equal. I also have tailSafe
I quite like the argument that take is a total function and as such
all its return values are from teh specificed range. I can also see
the logic in
take n [] = [] where n 0
taking n from nothing, or the empty set, returns nothing!
The same should apply to head and tail. head or tail of []
Hi
The same should apply to head and tail. head or tail of [] should be [].
What does the list think?
Disagree, strongly. Its not even possible for head, since [a] - a.
Wadler's theorems for free states that if head is given an empty list
the _only_ thing it can do is crash.
Thanks
Neil
On Wed, 12 Sep 2007, PR Stanley wrote:
I quite like the argument that take is a total function and as such all its
return values are from teh specificed range. I can also see the logic in
take n [] = [] where n 0
taking n from nothing, or the empty set, returns nothing!
The same should apply
On 9/12/07, PR Stanley [EMAIL PROTECTED] wrote:
The same should apply to head and tail. head or tail of [] should be
Disagree, strongly. Its not even possible for head,
What's the logic behind this?
You don't need anything sophisticated for this. What possible total
function could have
PR Stanley wrote:
Hi
The same should apply to head and tail. head or tail of [] should
be [].
What does the list think?
Disagree, strongly. Its not even possible for head, since [a] - a.
Wadler's theorems for free states that if head is given an empty list
the _only_ thing it can do is
20 matches
Mail list logo
