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". (W
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
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
>
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 t
* 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] -
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
Haskell-Cafe
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] -- retu
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 :
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 uglyAndRatherLongCamelCaseNamesThatCouldBePerlOrE
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 l
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 e
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
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
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 h
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.
What's
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
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
Ne
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 [] sh
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 tai
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 wrappe
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
21 matches
Mail list logo
