From mail at joachim-breitner.de Mon Aug 6 14:25:58 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 06 Aug 2018 10:25:58 -0400
Subject: =?UTF-8?Q?GC=E2=80=99ing?= committee memberships
Message-ID:
Dear Core Library Committee,
I am about to switch jobs, and that is a good time to review my
responsibilities. I noticed that the GHC Steering Committee is sucking
in all my committee-work-time and -energy, leaving none for the CLC,
where I have not done any work recently.
I would therefore like to officially vacate my seat on the CLC.
Cheers, and keep up the good work,
Joachim
--
Joachim Breitner
mail at joachim-breitner.de
http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL:
From ekmett at gmail.com Tue Aug 7 02:08:48 2018
From: ekmett at gmail.com (Edward Kmett)
Date: Mon, 6 Aug 2018 22:08:48 -0400
Subject: =?UTF-8?Q?Re=3A_GC=E2=80=99ing_committee_memberships?=
In-Reply-To:
References:
Message-ID:
Thank you, so much, for everything, Joachim.
I know at least one of the potential employers you considered is sad that
they didn't get you, but John seems equally happy that he'll get to work
with you! =)
Best of luck with your new job!
-Edward
On Mon, Aug 6, 2018 at 10:26 AM Joachim Breitner
wrote:
> Dear Core Library Committee,
>
> I am about to switch jobs, and that is a good time to review my
> responsibilities. I noticed that the GHC Steering Committee is sucking
> in all my committee-work-time and -energy, leaving none for the CLC,
> where I have not done any work recently.
>
> I would therefore like to officially vacate my seat on the CLC.
>
> Cheers, and keep up the good work,
> Joachim
>
> --
> Joachim Breitner
> mail at joachim-breitner.de
> http://www.joachim-breitner.de/
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ndospark320 at naver.com Thu Aug 9 02:33:14 2018
From: ndospark320 at naver.com (=?utf-8?B?67CV7Iug7ZmY?=)
Date: Thu, 09 Aug 2018 11:33:14 +0900
Subject: =?utf-8?B?TG9zdCBNb25hZEZpeCBpbnN0YW5jZXM=?=
Message-ID:
instance MonadFix Down where
mfix f = Down (fix (\x -> let
Down x' = f x
in x'
))
instance MonadFix Proxy where
mfix _ = Proxy
instance MonadFix U1 where
mfix _ = U1
instance MonadFix Complex where
mfix f = fix (realPart . f) :+ fix (imagPart . f)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Sat Aug 11 17:19:20 2018
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 11 Aug 2018 13:19:20 -0400
Subject: Proposal: add two more Applicative and Monad adapters
Message-ID:
We currently offer liftA, liftM, liftM2, and ap to implement Functor and
Applicative methods in terms of Applicative and Monad ones. But there are a
couple other functions in that general vein that are missing. I propose
that we should add at least replaceA, and perhaps also beforeM.
-- (<$) = replaceA
-- This may be better than the default if there is
-- an optimized definition of *> (which may be
-- based on an optimized >>).
replaceA :: Applicative f => a -> f x -> f a
replaceA a fa = fa *> pure a
-- (<*) = beforeM
-- This may be better than the default if there is
-- an optimized definition of <$, or if <$ is defined as
-- replaceA and *> is optimized.
beforeM :: Monad f => f a -> f x -> f a
beforeM fa fx = fa >>= \a -> a <$ fx
Why a <$ fx and not fx >> pure a? Because <$ could be implemented
specially, and is unlikely to be implemented by hand using <* if there
isn't a custom <*.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Sat Aug 11 17:39:03 2018
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 11 Aug 2018 13:39:03 -0400
Subject: Proposal: add two more Applicative and Monad adapters
In-Reply-To:
References:
Message-ID:
Also worth considering:
manyM :: (Alternative f, Monad f) => f a -> f [a]
manyM v = many_v
where
many_v = do
ma <- optional v
case ma of
Nothing -> pure []
Just a -> liftA2 (:) a many_v
someM :: (Alternative f, Monad f) => f a -> f [a]
someM v = liftA2 (:) v (manyM v)
Unlike the default definitions, these bound backtracking when (<|>)
represents that.
On Sat, Aug 11, 2018, 1:19 PM David Feuer wrote:
> We currently offer liftA, liftM, liftM2, and ap to implement Functor and
> Applicative methods in terms of Applicative and Monad ones. But there are a
> couple other functions in that general vein that are missing. I propose
> that we should add at least replaceA, and perhaps also beforeM.
>
> -- (<$) = replaceA
> -- This may be better than the default if there is
> -- an optimized definition of *> (which may be
> -- based on an optimized >>).
> replaceA :: Applicative f => a -> f x -> f a
> replaceA a fa = fa *> pure a
>
> -- (<*) = beforeM
> -- This may be better than the default if there is
> -- an optimized definition of <$, or if <$ is defined as
> -- replaceA and *> is optimized.
> beforeM :: Monad f => f a -> f x -> f a
> beforeM fa fx = fa >>= \a -> a <$ fx
>
> Why a <$ fx and not fx >> pure a? Because <$ could be implemented
> specially, and is unlikely to be implemented by hand using <* if there
> isn't a custom <*.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ndospark320 at naver.com Thu Aug 30 09:09:07 2018
From: ndospark320 at naver.com (=?utf-8?B?67CV7Iug7ZmY?=)
Date: Thu, 30 Aug 2018 18:09:07 +0900
Subject: =?utf-8?B?IlNhZmVyIiBpbXBsZW1lbnRhdGlvbiBvZiBEYXRhLkxpc3QuTm9uRW1wdHkgKGFuZCBzbw==?=
=?utf-8?B?bWUgb3RoZXIgc3VnZ2VzdGlvbnMp?=
Message-ID:
Those implementations using the nontotal `fromList`seem inefficient and potentially dangerous.
To eliminate those, I wrote a modification of the original file, which is enclosed.
Some other suggestions:
`insertBy` for `NonEmpty`s
`NonEmpty [a]` to `[NonEmpty a]` transposition
Add fixity for (:|) as `infixl 4 :|`
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NonEmpty.hs
Type: text/x-haskell
Size: 17848 bytes
Desc: not available
URL:
From rae at cs.brynmawr.edu Fri Aug 31 00:10:21 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Thu, 30 Aug 2018 20:10:21 -0400
Subject: Mark partial functions as such
Message-ID: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
Proposal: Mark partial functions in `base` as partial
Motivation: I'm about to teach Haskell to a classful of beginners. In my experience, they will soon reach for functions like `head` and `tail`, because pattern-matching is foreign to them. I would love just to be able to say "Don't use partial functions", but many students will not easily be able to tell partial functions from total ones.
I do expect this problem to work itself out rather quickly, and then students will be able to identify partial functions, but loudly marking partial functions as partial seems like a small service to everyone and a bigger one to newbies. I don't see any downsides.
Thoughts?
Thanks,
Richard
From chessai1996 at gmail.com Fri Aug 31 00:12:00 2018
From: chessai1996 at gmail.com (Daniel Cartwright)
Date: Thu, 30 Aug 2018 20:12:00 -0400
Subject: Mark partial functions as such
In-Reply-To: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
Message-ID:
+1, I've always thought it should be like this
On Thu, Aug 30, 2018, 8:10 PM Richard Eisenberg wrote:
> Proposal: Mark partial functions in `base` as partial
>
> Motivation: I'm about to teach Haskell to a classful of beginners. In my
> experience, they will soon reach for functions like `head` and `tail`,
> because pattern-matching is foreign to them. I would love just to be able
> to say "Don't use partial functions", but many students will not easily be
> able to tell partial functions from total ones.
>
> I do expect this problem to work itself out rather quickly, and then
> students will be able to identify partial functions, but loudly marking
> partial functions as partial seems like a small service to everyone and a
> bigger one to newbies. I don't see any downsides.
>
> Thoughts?
>
> Thanks,
> Richard
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From rae at cs.brynmawr.edu Fri Aug 31 00:13:43 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Thu, 30 Aug 2018 20:13:43 -0400
Subject: Mark partial functions as such
In-Reply-To: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
Message-ID: <212D060C-9F7A-4BB5-88FB-59EF84B26C96@cs.brynmawr.edu>
Just to clarify here: all I mean is that we should include the word "Partial" in the Haddock documentation -- no deprecation or warning, just documentation.
Richard
> On Aug 30, 2018, at 8:10 PM, Richard Eisenberg wrote:
>
> Proposal: Mark partial functions in `base` as partial
>
> Motivation: I'm about to teach Haskell to a classful of beginners. In my experience, they will soon reach for functions like `head` and `tail`, because pattern-matching is foreign to them. I would love just to be able to say "Don't use partial functions", but many students will not easily be able to tell partial functions from total ones.
>
> I do expect this problem to work itself out rather quickly, and then students will be able to identify partial functions, but loudly marking partial functions as partial seems like a small service to everyone and a bigger one to newbies. I don't see any downsides.
>
> Thoughts?
>
> Thanks,
> Richard
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
From chessai1996 at gmail.com Fri Aug 31 00:14:45 2018
From: chessai1996 at gmail.com (Daniel Cartwright)
Date: Thu, 30 Aug 2018 20:14:45 -0400
Subject: Mark partial functions as such
In-Reply-To: <212D060C-9F7A-4BB5-88FB-59EF84B26C96@cs.brynmawr.edu>
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
<212D060C-9F7A-4BB5-88FB-59EF84B26C96@cs.brynmawr.edu>
Message-ID:
That's fine, still a +1 from me
On Thu, Aug 30, 2018, 8:13 PM Richard Eisenberg wrote:
> Just to clarify here: all I mean is that we should include the word
> "Partial" in the Haddock documentation -- no deprecation or warning, just
> documentation.
>
> Richard
>
> > On Aug 30, 2018, at 8:10 PM, Richard Eisenberg
> wrote:
> >
> > Proposal: Mark partial functions in `base` as partial
> >
> > Motivation: I'm about to teach Haskell to a classful of beginners. In my
> experience, they will soon reach for functions like `head` and `tail`,
> because pattern-matching is foreign to them. I would love just to be able
> to say "Don't use partial functions", but many students will not easily be
> able to tell partial functions from total ones.
> >
> > I do expect this problem to work itself out rather quickly, and then
> students will be able to identify partial functions, but loudly marking
> partial functions as partial seems like a small service to everyone and a
> bigger one to newbies. I don't see any downsides.
> >
> > Thoughts?
> >
> > Thanks,
> > Richard
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From dhelta.diaz at gmail.com Fri Aug 31 02:05:22 2018
From: dhelta.diaz at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz_Casanueva?=)
Date: Fri, 31 Aug 2018 04:05:22 +0200
Subject: Mark partial functions as such
In-Reply-To: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
Message-ID:
+1 from me too. The partiality of a function seems to me like something
that should be documented.
Best,
Daniel
Am Fr., 31. Aug. 2018 um 02:10 Uhr schrieb Richard Eisenberg <
rae at cs.brynmawr.edu>:
> Proposal: Mark partial functions in `base` as partial
>
> Motivation: I'm about to teach Haskell to a classful of beginners. In my
> experience, they will soon reach for functions like `head` and `tail`,
> because pattern-matching is foreign to them. I would love just to be able
> to say "Don't use partial functions", but many students will not easily be
> able to tell partial functions from total ones.
>
> I do expect this problem to work itself out rather quickly, and then
> students will be able to identify partial functions, but loudly marking
> partial functions as partial seems like a small service to everyone and a
> bigger one to newbies. I don't see any downsides.
>
> Thoughts?
>
> Thanks,
> Richard
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Fri Aug 31 02:09:11 2018
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 30 Aug 2018 22:09:11 -0400
Subject: Mark partial functions as such
In-Reply-To:
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
Message-ID:
Yes, I think so. What about functions like length? length (repeat ()) is
bottom. repeat () is not bottom. Ergo, length is partial. But I don't think
we want to say that!
On Thu, Aug 30, 2018, 10:05 PM Daniel Díaz Casanueva
wrote:
> +1 from me too. The partiality of a function seems to me like something
> that should be documented.
>
> Best,
> Daniel
>
> Am Fr., 31. Aug. 2018 um 02:10 Uhr schrieb Richard Eisenberg <
> rae at cs.brynmawr.edu>:
>
>> Proposal: Mark partial functions in `base` as partial
>>
>> Motivation: I'm about to teach Haskell to a classful of beginners. In my
>> experience, they will soon reach for functions like `head` and `tail`,
>> because pattern-matching is foreign to them. I would love just to be able
>> to say "Don't use partial functions", but many students will not easily be
>> able to tell partial functions from total ones.
>>
>> I do expect this problem to work itself out rather quickly, and then
>> students will be able to identify partial functions, but loudly marking
>> partial functions as partial seems like a small service to everyone and a
>> bigger one to newbies. I don't see any downsides.
>>
>> Thoughts?
>>
>> Thanks,
>> Richard
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From dhelta.diaz at gmail.com Fri Aug 31 02:16:51 2018
From: dhelta.diaz at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz_Casanueva?=)
Date: Fri, 31 Aug 2018 04:16:51 +0200
Subject: Mark partial functions as such
In-Reply-To:
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
Message-ID:
Why not? I don't think mentioning that length doesn't work with infinite
lists will do any harm.
I think many people make a distinction between partiality due to endless
evaluation and partiality due to a call to "error". But I still think
documenting either of both things can be helpful.
Best,
Daniel
Am Fr., 31. Aug. 2018 um 04:09 Uhr schrieb David Feuer <
david.feuer at gmail.com>:
> Yes, I think so. What about functions like length? length (repeat ()) is
> bottom. repeat () is not bottom. Ergo, length is partial. But I don't think
> we want to say that!
>
> On Thu, Aug 30, 2018, 10:05 PM Daniel Díaz Casanueva <
> dhelta.diaz at gmail.com> wrote:
>
>> +1 from me too. The partiality of a function seems to me like something
>> that should be documented.
>>
>> Best,
>> Daniel
>>
>> Am Fr., 31. Aug. 2018 um 02:10 Uhr schrieb Richard Eisenberg <
>> rae at cs.brynmawr.edu>:
>>
>>> Proposal: Mark partial functions in `base` as partial
>>>
>>> Motivation: I'm about to teach Haskell to a classful of beginners. In my
>>> experience, they will soon reach for functions like `head` and `tail`,
>>> because pattern-matching is foreign to them. I would love just to be able
>>> to say "Don't use partial functions", but many students will not easily be
>>> able to tell partial functions from total ones.
>>>
>>> I do expect this problem to work itself out rather quickly, and then
>>> students will be able to identify partial functions, but loudly marking
>>> partial functions as partial seems like a small service to everyone and a
>>> bigger one to newbies. I don't see any downsides.
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> Richard
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From emertens at gmail.com Fri Aug 31 02:19:00 2018
From: emertens at gmail.com (Eric Mertens)
Date: Thu, 30 Aug 2018 19:19:00 -0700
Subject: Mark partial functions as such
In-Reply-To:
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
Message-ID:
I think this comes down to just documenting things like how strict functions are and how they behave on various classes of inputs. These are good things to document. It doesn’t just have to be about a boolean flag “partial” paste on a bunch of definitions.
> On Aug 30, 2018, at 7:16 PM, Daniel Díaz Casanueva wrote:
>
> Why not? I don't think mentioning that length doesn't work with infinite lists will do any harm.
>
> I think many people make a distinction between partiality due to endless evaluation and partiality due to a call to "error". But I still think documenting either of both things can be helpful.
>
> Best,
> Daniel
>
> Am Fr., 31. Aug. 2018 um 04:09 Uhr schrieb David Feuer >:
> Yes, I think so. What about functions like length? length (repeat ()) is bottom. repeat () is not bottom. Ergo, length is partial. But I don't think we want to say that!
>
> On Thu, Aug 30, 2018, 10:05 PM Daniel Díaz Casanueva > wrote:
> +1 from me too. The partiality of a function seems to me like something that should be documented.
>
> Best,
> Daniel
>
> Am Fr., 31. Aug. 2018 um 02:10 Uhr schrieb Richard Eisenberg >:
> Proposal: Mark partial functions in `base` as partial
>
> Motivation: I'm about to teach Haskell to a classful of beginners. In my experience, they will soon reach for functions like `head` and `tail`, because pattern-matching is foreign to them. I would love just to be able to say "Don't use partial functions", but many students will not easily be able to tell partial functions from total ones.
>
> I do expect this problem to work itself out rather quickly, and then students will be able to identify partial functions, but loudly marking partial functions as partial seems like a small service to everyone and a bigger one to newbies. I don't see any downsides.
>
> Thoughts?
>
> Thanks,
> Richard
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Fri Aug 31 02:22:16 2018
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 30 Aug 2018 22:22:16 -0400
Subject: Mark partial functions as such
In-Reply-To:
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
Message-ID:
Yup! Just wanted to make sure it didn't end up being the latter.
On Thu, Aug 30, 2018, 10:19 PM Eric Mertens wrote:
> I think this comes down to just documenting things like how strict
> functions are and how they behave on various classes of inputs. These are
> good things to document. It doesn’t just have to be about a boolean flag
> “partial” paste on a bunch of definitions.
>
> On Aug 30, 2018, at 7:16 PM, Daniel Díaz Casanueva
> wrote:
>
> Why not? I don't think mentioning that length doesn't work with infinite
> lists will do any harm.
>
> I think many people make a distinction between partiality due to endless
> evaluation and partiality due to a call to "error". But I still think
> documenting either of both things can be helpful.
>
> Best,
> Daniel
>
> Am Fr., 31. Aug. 2018 um 04:09 Uhr schrieb David Feuer <
> david.feuer at gmail.com>:
>
>> Yes, I think so. What about functions like length? length (repeat ()) is
>> bottom. repeat () is not bottom. Ergo, length is partial. But I don't think
>> we want to say that!
>>
>> On Thu, Aug 30, 2018, 10:05 PM Daniel Díaz Casanueva <
>> dhelta.diaz at gmail.com> wrote:
>>
>>> +1 from me too. The partiality of a function seems to me like something
>>> that should be documented.
>>>
>>> Best,
>>> Daniel
>>>
>>> Am Fr., 31. Aug. 2018 um 02:10 Uhr schrieb Richard Eisenberg <
>>> rae at cs.brynmawr.edu>:
>>>
>>>> Proposal: Mark partial functions in `base` as partial
>>>>
>>>> Motivation: I'm about to teach Haskell to a classful of beginners. In
>>>> my experience, they will soon reach for functions like `head` and `tail`,
>>>> because pattern-matching is foreign to them. I would love just to be able
>>>> to say "Don't use partial functions", but many students will not easily be
>>>> able to tell partial functions from total ones.
>>>>
>>>> I do expect this problem to work itself out rather quickly, and then
>>>> students will be able to identify partial functions, but loudly marking
>>>> partial functions as partial seems like a small service to everyone and a
>>>> bigger one to newbies. I don't see any downsides.
>>>>
>>>> Thoughts?
>>>>
>>>> Thanks,
>>>> Richard
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From raabe at froglogic.com Fri Aug 31 06:21:55 2018
From: raabe at froglogic.com (Frerich Raabe)
Date: Fri, 31 Aug 2018 08:21:55 +0200
Subject: Mark partial functions as such
In-Reply-To:
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
Message-ID:
Hi David,
On 2018-08-31 04:09, David Feuer wrote:
> What about functions like length? length (repeat ()) is bottom. repeat () is
> not bottom. Ergo, length is partial.
This caught me by surprise - I would have never considered 'length' to be a
partial function! Maybe I don't quite understand what it means for some
expression to be 'bottom' (I thought that's the same as 'undefined').
My naive understanding was that a partial function is one which has no
definition for certain arguments; in particular, it has no definition which
could be used while doing equational reasoning by hand, on a piece of paper
(i.e. without running the program).
It appears that this is not quite correct -- instead, any function which
fails to return anything (at runtime!) for certain arguments is partial? E.g.
'sort' would be partial or even 'elem' (consider 'True `elem` repeat False')?
--
Frerich Raabe - raabe at froglogic.com
www.froglogic.com - Multi-Platform GUI Testing
From Henrik.Nilsson at nottingham.ac.uk Fri Aug 31 10:45:29 2018
From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson)
Date: Fri, 31 Aug 2018 11:45:29 +0100
Subject: Mark partial functions as such
In-Reply-To:
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
Message-ID: <5B891C49.5010106@exmail.nottingham.ac.uk>
Hi,
Frerich Raabe wrote:
> On 2018-08-31 04:09, David Feuer wrote:
> > What about functions like length? length (repeat ()) is bottom.
> > repeat () is not bottom. Ergo, length is partial.
>
> This caught me by surprise - I would have never considered 'length'
> to be a partial function! Maybe I don't quite understand what it
> means for some expression to be 'bottom' (I thought that's the same
> as 'undefined').
We have to be a bit careful with attributing blame for failure.
By David's argument, e.g. "fst" would also be "partial". Consider:
(_|_, _|_) /= _|_
But
fst (_|_, _|_) == _|_
But the bottom here does not originate in the computation of "fst" as
such, but in the computation of the *argument* to "fst".
Similarly for "length" above: "length" is not to blame for the
fact that
length (repeat ()) == _|_
It's simply that computation of the argument to length takes a very(!)
long time.
In a language with strict semantics, this is of course no surprise
at all, and I suspect no one would suggest that a function
like "length" is partial in a strict setting just because the
overall computation fails to terminate when the computation of
an argument does.
> My naive understanding was that a partial function is one which has
> no definition for certain arguments; in particular, it has no
> definition which could be used while doing equational reasoning by
> hand, on a piece of paper (i.e. without running the program).
>
> It appears that this is not quite correct -- instead, any function
> which fails to return anything (at runtime!) for certain arguments is
> partial? E.g. 'sort' would be partial or even 'elem' (consider 'True
> `elem` repeat False')?
I'd say neither "sort" nor "elem" is partial for the same reason.
As to the original suggestion of marking functions as partial, I think
that's fine, as long as one is careful to explain exactly what is meant.
(And documenting (different forms of) strictness would be fine too.)
But one should bear in mind that there are functions that are
partial for other reasons that pattern matching failure, in particular
numerical functions like division, square root, ...
(And the full story of floating point arithmetic with infinities
and NaNs etc. is of course quite complicated.)
Students (well, any programmer) should of course be aware that one have
to be extra careful when using partial functions, and certainly also
encouraged to seek alternative formulations, but just saying "Don't use
partial functions" is not the full story.
Best,
/Henrik
This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment.
Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored
where permitted by law.
From wolfgang-it at jeltsch.info Fri Aug 31 11:04:17 2018
From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch)
Date: Fri, 31 Aug 2018 14:04:17 +0300
Subject: Mark partial functions as such
In-Reply-To:
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
Message-ID: <1535713457.2343.84.camel@jeltsch.info>
Am Freitag, den 31.08.2018, 08:21 +0200 schrieb Frerich Raabe:
> This caught me by surprise - I would have never considered 'length' to
> be a partial function! Maybe I don't quite understand what it means
> for some expression to be 'bottom' (I thought that's the same as
> 'undefined').
>
> My naive understanding was that a partial function is one which has no
> definition for certain arguments; in particular, it has no definition
> which could be used while doing equational reasoning by hand, on a
> piece of paper (i.e. without running the program).
>
> It appears that this is not quite correct -- instead, any function
> which fails to return anything (at runtime!) for certain arguments is
> partial? E.g. 'sort' would be partial or even 'elem' (consider 'True
> `elem` repeat False')?
The word “partial” might not have a precise definition in the context of
Haskell. In particular, it might not necessarily be defined in terms of
⊥ (bottom). However, the notion of ⊥ itself does have a precise
definition.
⊥ is a special value that every type contains. A consequence of this is
that there are also values like ⊥ : ⊥.
A good way to think about ⊥ is that ⊥ marks the absence of any
information. So the value of an expression is ⊥ if there is a lack of an
appropriate alternative in a case distinction but also if there is a
recursion that doesn’t produce any data.
For example, if zeros is defined via the equation zeroes = 0 : zeroes,
you know that zeroes must be of the form 0 : _; so it cannot be ⊥.
However, if unknown is defined via the equation unknown = unknown, there
is nothing you can learn about any information that unknown would
contain; so unknown is ⊥.
Mathematically, the values of each type form a domain such that ⊥ is the
minimum and each data constructor is an order-preserving function. When
defining a value recursively, Haskell will give you the *least* solution
of the defining equation. The equation zeros = 0 : zeros has only one
solution (0 : 0 : 0 : …). The equation unknown = unknown, on the other
hand, has every value as a solution, and thus the least of them, ⊥, is
picked as the value for unknown.
All the best,
Wolfgang
From Andrew.Butterfield at scss.tcd.ie Fri Aug 31 08:43:10 2018
From: Andrew.Butterfield at scss.tcd.ie (Andrew Butterfield)
Date: Fri, 31 Aug 2018 09:43:10 +0100
Subject: Mark partial functions as such
In-Reply-To:
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
Message-ID:
Dear David,
given that "data [a] = [] | (a : [a])" in Haskell is viewed co-inductively and hence admits infinite lists,
then any function f : [a] -> b is total only if it returns a result.
Does this mean it must terminate?
In a strict world, yes.
In the lazy world, it's a little more complicated than that.
Consider map id :: [a] -> [a]
is map id partial? It won't terminate if given an infinite list, but it will produce partial results on demand indefinitely - so I say it is total.
However , length applied to [0..] (say) will never return any partial or complete result, and so I would say it's partial.
I too am going to start teaching Haskell newbies, so this is of interest - to what extend to we use "stories for children"
One suggestion: if you don't start with laziness, and they initially consider lists as finite, then length :: [a] -> Int is total, where [a] is interpreted as finite lists.
When laziness enters the picture, then points out that having [a] include infinite lists means that some hitherto total function become partial, on that expanded domain.
Perhaps the added documentation should also comment for list and ADT based functions where the infinite forms influence totality/partiality?
Regards, Andrew
> On 31 Aug 2018, at 03:09, David Feuer wrote:
>
> Yes, I think so. What about functions like length? length (repeat ()) is bottom. repeat () is not bottom. Ergo, length is partial. But I don't think we want to say that!
>
> On Thu, Aug 30, 2018, 10:05 PM Daniel Díaz Casanueva > wrote:
> +1 from me too. The partiality of a function seems to me like something that should be documented.
>
> Best,
> Daniel
>
> Am Fr., 31. Aug. 2018 um 02:10 Uhr schrieb Richard Eisenberg >:
> Proposal: Mark partial functions in `base` as partial
>
> Motivation: I'm about to teach Haskell to a classful of beginners. In my experience, they will soon reach for functions like `head` and `tail`, because pattern-matching is foreign to them. I would love just to be able to say "Don't use partial functions", but many students will not easily be able to tell partial functions from total ones.
>
> I do expect this problem to work itself out rather quickly, and then students will be able to identify partial functions, but loudly marking partial functions as partial seems like a small service to everyone and a bigger one to newbies. I don't see any downsides.
>
> Thoughts?
>
> Thanks,
> Richard
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--------------------------------------------------------------------
Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
Lero at TCD, Head of Foundations & Methods Research Group
School of Computer Science and Statistics,
Room G.39, O'Reilly Institute, Trinity College, University of Dublin
http://www.scss.tcd.ie/Andrew.Butterfield/
--------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From andrew.thaddeus at gmail.com Fri Aug 31 12:28:09 2018
From: andrew.thaddeus at gmail.com (Andrew Martin)
Date: Fri, 31 Aug 2018 08:28:09 -0400
Subject: Mark partial functions as such
In-Reply-To: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
Message-ID:
I'm strongly +1 on this.
On Thu, Aug 30, 2018 at 8:10 PM Richard Eisenberg
wrote:
> Proposal: Mark partial functions in `base` as partial
>
> Motivation: I'm about to teach Haskell to a classful of beginners. In my
> experience, they will soon reach for functions like `head` and `tail`,
> because pattern-matching is foreign to them. I would love just to be able
> to say "Don't use partial functions", but many students will not easily be
> able to tell partial functions from total ones.
>
> I do expect this problem to work itself out rather quickly, and then
> students will be able to identify partial functions, but loudly marking
> partial functions as partial seems like a small service to everyone and a
> bigger one to newbies. I don't see any downsides.
>
> Thoughts?
>
> Thanks,
> Richard
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
--
-Andrew Thaddeus Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Fri Aug 31 12:46:39 2018
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 31 Aug 2018 08:46:39 -0400
Subject: Mark partial functions as such
In-Reply-To: <1535713457.2343.84.camel@jeltsch.info>
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
<1535713457.2343.84.camel@jeltsch.info>
Message-ID:
I think it actually can be made precise, with some more knowledge than I
have. Roughly speaking, a function is total if its result is fully defined
(contains no bottoms) whenever its argument is fully defined.
On Fri, Aug 31, 2018, 7:04 AM Wolfgang Jeltsch
wrote:
> Am Freitag, den 31.08.2018, 08:21 +0200 schrieb Frerich Raabe:
> > This caught me by surprise - I would have never considered 'length' to
> > be a partial function! Maybe I don't quite understand what it means
> > for some expression to be 'bottom' (I thought that's the same as
> > 'undefined').
> >
> > My naive understanding was that a partial function is one which has no
> > definition for certain arguments; in particular, it has no definition
> > which could be used while doing equational reasoning by hand, on a
> > piece of paper (i.e. without running the program).
> >
> > It appears that this is not quite correct -- instead, any function
> > which fails to return anything (at runtime!) for certain arguments is
> > partial? E.g. 'sort' would be partial or even 'elem' (consider 'True
> > `elem` repeat False')?
>
> The word “partial” might not have a precise definition in the context of
> Haskell. In particular, it might not necessarily be defined in terms of
> ⊥ (bottom). However, the notion of ⊥ itself does have a precise
> definition.
>
> ⊥ is a special value that every type contains. A consequence of this is
> that there are also values like ⊥ : ⊥.
>
> A good way to think about ⊥ is that ⊥ marks the absence of any
> information. So the value of an expression is ⊥ if there is a lack of an
> appropriate alternative in a case distinction but also if there is a
> recursion that doesn’t produce any data.
>
> For example, if zeros is defined via the equation zeroes = 0 : zeroes,
> you know that zeroes must be of the form 0 : _; so it cannot be ⊥.
> However, if unknown is defined via the equation unknown = unknown, there
> is nothing you can learn about any information that unknown would
> contain; so unknown is ⊥.
>
> Mathematically, the values of each type form a domain such that ⊥ is the
> minimum and each data constructor is an order-preserving function. When
> defining a value recursively, Haskell will give you the *least* solution
> of the defining equation. The equation zeros = 0 : zeros has only one
> solution (0 : 0 : 0 : …). The equation unknown = unknown, on the other
> hand, has every value as a solution, and thus the least of them, ⊥, is
> picked as the value for unknown.
>
> All the best,
> Wolfgang
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From zemyla at gmail.com Fri Aug 31 12:50:56 2018
From: zemyla at gmail.com (Zemyla)
Date: Fri, 31 Aug 2018 07:50:56 -0500
Subject: Mark partial functions as such
In-Reply-To:
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
Message-ID:
I feel like there's a difference between partial functions in the
sense of length and partial functions in the sense of head.
If you have a partiality monad like the free monad over Identity:
data Partial a = Done a | NotYet (Partial a)
instance Monad Partial where
return = Done
Done a >>= f = f a
NotYet m >>= f = NotYet $ m >>= f
then length has a sensible and productive implementation in terms of it:
partialLength :: [a] -> Partial Int
partialLength = go 0 where
go n ls = seq n $ case ls of
[] -> Done n
_:ls' -> NotYet $ go (n + 1) ls'
This is similar to the mechanism that Agda and Idris use to denote a
potentially non-terminating result; with it, these languages are
Turing complete.
head and tail aren't like that, and should be marked differently in
the documentation.
On Fri, Aug 31, 2018 at 7:28 AM, Andrew Martin
wrote:
> I'm strongly +1 on this.
>
> On Thu, Aug 30, 2018 at 8:10 PM Richard Eisenberg
> wrote:
>>
>> Proposal: Mark partial functions in `base` as partial
>>
>> Motivation: I'm about to teach Haskell to a classful of beginners. In my
>> experience, they will soon reach for functions like `head` and `tail`,
>> because pattern-matching is foreign to them. I would love just to be able to
>> say "Don't use partial functions", but many students will not easily be able
>> to tell partial functions from total ones.
>>
>> I do expect this problem to work itself out rather quickly, and then
>> students will be able to identify partial functions, but loudly marking
>> partial functions as partial seems like a small service to everyone and a
>> bigger one to newbies. I don't see any downsides.
>>
>> Thoughts?
>>
>> Thanks,
>> Richard
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
>
> --
> -Andrew Thaddeus Martin
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
From Andrew.Butterfield at scss.tcd.ie Fri Aug 31 08:34:31 2018
From: Andrew.Butterfield at scss.tcd.ie (Andrew Butterfield)
Date: Fri, 31 Aug 2018 09:34:31 +0100
Subject: Mark partial functions as such
In-Reply-To:
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
Message-ID:
+1 from me too.
How about also adding in (to the documentation) the pre-condition - i.e. an identification of the inputs for which it will terminate and produce a result
(where this is possible to state, of course).
> On 31 Aug 2018, at 03:05, Daniel Díaz Casanueva wrote:
>
> +1 from me too. The partiality of a function seems to me like something that should be documented.
>
> Best,
> Daniel
>
> Am Fr., 31. Aug. 2018 um 02:10 Uhr schrieb Richard Eisenberg >:
> Proposal: Mark partial functions in `base` as partial
>
> Motivation: I'm about to teach Haskell to a classful of beginners. In my experience, they will soon reach for functions like `head` and `tail`, because pattern-matching is foreign to them. I would love just to be able to say "Don't use partial functions", but many students will not easily be able to tell partial functions from total ones.
>
> I do expect this problem to work itself out rather quickly, and then students will be able to identify partial functions, but loudly marking partial functions as partial seems like a small service to everyone and a bigger one to newbies. I don't see any downsides.
>
> Thoughts?
>
> Thanks,
> Richard
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--------------------------------------------------------------------
Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
Lero at TCD, Head of Foundations & Methods Research Group
School of Computer Science and Statistics,
Room G.39, O'Reilly Institute, Trinity College, University of Dublin
http://www.scss.tcd.ie/Andrew.Butterfield/
--------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From rae at cs.brynmawr.edu Fri Aug 31 14:49:41 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Fri, 31 Aug 2018 10:49:41 -0400
Subject: Mark partial functions as such
In-Reply-To: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
Message-ID: <8FAC7383-B509-464A-9009-5D7C8C355538@cs.brynmawr.edu>
In a response not cc'd to the list, a contributor (not sure if they want public identification) suggests:
> I think we want something like "partial even given input you can successfully DeepSeq"
That's the specification of the feature I'm after. I think all the commentary about infinite lists, etc., would lead also to good documentation additions. (For example, it would be fantastic if every function precisely documented its strictness, preferably with some standard notation, but this is not the problem I'm trying to solve here.)
Also, it was suggested that the documentation be checked -- that is, we could imagine a {-# TOTAL ... #-} or {-# PARTIAL ... #-} pragma that GHC could check on compilation and Haddock could include in the documentation. This would also be great, but much more than I'm proposing here.
Maybe here's a concrete example:
> -- | /Contains a call to 'error'./ Extract the first element of a list, which must be non-empty.
> head :: [a] -> a
In the end, it's the call to error that I want noted. Of course, having a similar note on functions like div (where the problem isn't a call to error) and length (that will loop on infinite lists) is good, but not really what I'm proposing here.
Thanks,
Richard
> On Aug 30, 2018, at 8:10 PM, Richard Eisenberg wrote:
>
> Proposal: Mark partial functions in `base` as partial
>
> Motivation: I'm about to teach Haskell to a classful of beginners. In my experience, they will soon reach for functions like `head` and `tail`, because pattern-matching is foreign to them. I would love just to be able to say "Don't use partial functions", but many students will not easily be able to tell partial functions from total ones.
>
> I do expect this problem to work itself out rather quickly, and then students will be able to identify partial functions, but loudly marking partial functions as partial seems like a small service to everyone and a bigger one to newbies. I don't see any downsides.
>
> Thoughts?
>
> Thanks,
> Richard
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
From david.feuer at gmail.com Fri Aug 31 14:53:58 2018
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 31 Aug 2018 10:53:58 -0400
Subject: Mark partial functions as such
In-Reply-To: <8FAC7383-B509-464A-9009-5D7C8C355538@cs.brynmawr.edu>
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
<8FAC7383-B509-464A-9009-5D7C8C355538@cs.brynmawr.edu>
Message-ID:
Why isn't the call to error in div what you mean?
On Fri, Aug 31, 2018, 10:49 AM Richard Eisenberg
wrote:
> In a response not cc'd to the list, a contributor (not sure if they want
> public identification) suggests:
>
> > I think we want something like "partial even given input you can
> successfully DeepSeq"
>
> That's the specification of the feature I'm after. I think all the
> commentary about infinite lists, etc., would lead also to good
> documentation additions. (For example, it would be fantastic if every
> function precisely documented its strictness, preferably with some standard
> notation, but this is not the problem I'm trying to solve here.)
>
> Also, it was suggested that the documentation be checked -- that is, we
> could imagine a {-# TOTAL ... #-} or {-# PARTIAL ... #-} pragma that GHC
> could check on compilation and Haddock could include in the documentation.
> This would also be great, but much more than I'm proposing here.
>
> Maybe here's a concrete example:
>
> > -- | /Contains a call to 'error'./ Extract the first element of a list,
> which must be non-empty.
> > head :: [a] -> a
>
> In the end, it's the call to error that I want noted. Of course, having a
> similar note on functions like div (where the problem isn't a call to
> error) and length (that will loop on infinite lists) is good, but not
> really what I'm proposing here.
>
> Thanks,
> Richard
>
> > On Aug 30, 2018, at 8:10 PM, Richard Eisenberg
> wrote:
> >
> > Proposal: Mark partial functions in `base` as partial
> >
> > Motivation: I'm about to teach Haskell to a classful of beginners. In my
> experience, they will soon reach for functions like `head` and `tail`,
> because pattern-matching is foreign to them. I would love just to be able
> to say "Don't use partial functions", but many students will not easily be
> able to tell partial functions from total ones.
> >
> > I do expect this problem to work itself out rather quickly, and then
> students will be able to identify partial functions, but loudly marking
> partial functions as partial seems like a small service to everyone and a
> bigger one to newbies. I don't see any downsides.
> >
> > Thoughts?
> >
> > Thanks,
> > Richard
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From rae at cs.brynmawr.edu Fri Aug 31 14:57:03 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Fri, 31 Aug 2018 10:57:03 -0400
Subject: Mark partial functions as such
In-Reply-To:
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
<8FAC7383-B509-464A-9009-5D7C8C355538@cs.brynmawr.edu>
Message-ID:
Because I was silly and didn't look for it. That can and should be included, yes.
> On Aug 31, 2018, at 10:53 AM, David Feuer wrote:
>
> Why isn't the call to error in div what you mean?
>
> On Fri, Aug 31, 2018, 10:49 AM Richard Eisenberg > wrote:
> In a response not cc'd to the list, a contributor (not sure if they want public identification) suggests:
>
> > I think we want something like "partial even given input you can successfully DeepSeq"
>
> That's the specification of the feature I'm after. I think all the commentary about infinite lists, etc., would lead also to good documentation additions. (For example, it would be fantastic if every function precisely documented its strictness, preferably with some standard notation, but this is not the problem I'm trying to solve here.)
>
> Also, it was suggested that the documentation be checked -- that is, we could imagine a {-# TOTAL ... #-} or {-# PARTIAL ... #-} pragma that GHC could check on compilation and Haddock could include in the documentation. This would also be great, but much more than I'm proposing here.
>
> Maybe here's a concrete example:
>
> > -- | /Contains a call to 'error'./ Extract the first element of a list, which must be non-empty.
> > head :: [a] -> a
>
> In the end, it's the call to error that I want noted. Of course, having a similar note on functions like div (where the problem isn't a call to error) and length (that will loop on infinite lists) is good, but not really what I'm proposing here.
>
> Thanks,
> Richard
>
> > On Aug 30, 2018, at 8:10 PM, Richard Eisenberg > wrote:
> >
> > Proposal: Mark partial functions in `base` as partial
> >
> > Motivation: I'm about to teach Haskell to a classful of beginners. In my experience, they will soon reach for functions like `head` and `tail`, because pattern-matching is foreign to them. I would love just to be able to say "Don't use partial functions", but many students will not easily be able to tell partial functions from total ones.
> >
> > I do expect this problem to work itself out rather quickly, and then students will be able to identify partial functions, but loudly marking partial functions as partial seems like a small service to everyone and a bigger one to newbies. I don't see any downsides.
> >
> > Thoughts?
> >
> > Thanks,
> > Richard
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From simon.jakobi at googlemail.com Fri Aug 31 15:21:16 2018
From: simon.jakobi at googlemail.com (Simon Jakobi)
Date: Fri, 31 Aug 2018 17:21:16 +0200
Subject: Mark partial functions as such
In-Reply-To: <212D060C-9F7A-4BB5-88FB-59EF84B26C96@cs.brynmawr.edu>
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
<212D060C-9F7A-4BB5-88FB-59EF84B26C96@cs.brynmawr.edu>
Message-ID:
(Sending this again, as I forgot to include the list)
Hi Richard,
I think that's a good idea!
What about typeclass methods where totality / partiality depends on the
instance like Foldable's foldl1? What do we mark partial in this case? The
method declaration? The instance? Both?
Cheers,
Simon
Am Fr., 31. Aug. 2018 um 02:13 Uhr schrieb Richard Eisenberg <
rae at cs.brynmawr.edu>:
> Just to clarify here: all I mean is that we should include the word
> "Partial" in the Haddock documentation -- no deprecation or warning, just
> documentation.
>
> Richard
>
> > On Aug 30, 2018, at 8:10 PM, Richard Eisenberg
> wrote:
> >
> > Proposal: Mark partial functions in `base` as partial
> >
> > Motivation: I'm about to teach Haskell to a classful of beginners. In my
> experience, they will soon reach for functions like `head` and `tail`,
> because pattern-matching is foreign to them. I would love just to be able
> to say "Don't use partial functions", but many students will not easily be
> able to tell partial functions from total ones.
> >
> > I do expect this problem to work itself out rather quickly, and then
> students will be able to identify partial functions, but loudly marking
> partial functions as partial seems like a small service to everyone and a
> bigger one to newbies. I don't see any downsides.
> >
> > Thoughts?
> >
> > Thanks,
> > Richard
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From Henrik.Nilsson at nottingham.ac.uk Fri Aug 31 15:36:15 2018
From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson)
Date: Fri, 31 Aug 2018 16:36:15 +0100
Subject: Mark partial functions as such
In-Reply-To:
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
<8FAC7383-B509-464A-9009-5D7C8C355538@cs.brynmawr.edu>
Message-ID: <5B89606F.3010000@exmail.nottingham.ac.uk>
Hi,
Richard Eisenberg wrote:
> Maybe here's a concrete example:
>
> > -- | /Contains a call to 'error'./ Extract the first element of a
> list, which must be non-empty.
> > head :: [a] -> a
>
> In the end, it's the call to error that I want noted.
Yes, whether the code of a function directly or indirectly calls "error"
is well-defined property that could be documented.
But note that this does not coincide with the following:
> > I think we want something like "partial even given input you can
> > successfully DeepSeq"
>
> That's the specification of the feature I'm after
Consider e.g.
apply f x = f x
As e.g.
apply head [] == _|_
we'd have to conclude by the above definition that "apply" is partial.
But it clearly does not "call error".
Just to be clear, this does not correspond to how I understand
partiality. Lots of higher order functions, like "map", then would have
to called partial. And I am not sure that would be so helpful for
the purpose of alerting (new) programmers to functions that one
might argue should be avoided.
So maybe something very clear and easy to understand, such as "contains
call to error" is the best approach.
Best,
/Henrik
This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment.
Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored
where permitted by law.
From ryan.trinkle at gmail.com Fri Aug 31 15:49:28 2018
From: ryan.trinkle at gmail.com (Ryan Trinkle)
Date: Fri, 31 Aug 2018 11:49:28 -0400
Subject: Mark partial functions as such
In-Reply-To: <5B89606F.3010000@exmail.nottingham.ac.uk>
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
<8FAC7383-B509-464A-9009-5D7C8C355538@cs.brynmawr.edu>
<5B89606F.3010000@exmail.nottingham.ac.uk>
Message-ID:
This is probably not really for the libraries list, but in the same vein as
this discussion, I think it would be extremely helpful to have a way of
banning functions that does *not* require changing the upstream library. I
would be thrilled to have a machine-checked ban on use of the 'head',
'tail', etc.
On Fri, Aug 31, 2018 at 11:36 AM Henrik Nilsson <
Henrik.Nilsson at nottingham.ac.uk> wrote:
> Hi,
>
> Richard Eisenberg wrote:
>
> > Maybe here's a concrete example:
> >
> > > -- | /Contains a call to 'error'./ Extract the first element of a
> > list, which must be non-empty.
> > > head :: [a] -> a
> >
> > In the end, it's the call to error that I want noted.
>
> Yes, whether the code of a function directly or indirectly calls "error"
> is well-defined property that could be documented.
>
> But note that this does not coincide with the following:
>
> > > I think we want something like "partial even given input you can
> > > successfully DeepSeq"
> >
> > That's the specification of the feature I'm after
>
> Consider e.g.
>
> apply f x = f x
>
> As e.g.
>
> apply head [] == _|_
>
> we'd have to conclude by the above definition that "apply" is partial.
> But it clearly does not "call error".
>
> Just to be clear, this does not correspond to how I understand
> partiality. Lots of higher order functions, like "map", then would have
> to called partial. And I am not sure that would be so helpful for
> the purpose of alerting (new) programmers to functions that one
> might argue should be avoided.
>
> So maybe something very clear and easy to understand, such as "contains
> call to error" is the best approach.
>
> Best,
>
> /Henrik
>
>
>
> This message and any attachment are intended solely for the addressee
> and may contain confidential information. If you have received this
> message in error, please contact the sender and delete the email and
> attachment.
>
> Any views or opinions expressed by the author of this email do not
> necessarily reflect the views of the University of Nottingham. Email
> communications with the University of Nottingham may be monitored
> where permitted by law.
>
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From lemming at henning-thielemann.de Fri Aug 31 15:53:54 2018
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri, 31 Aug 2018 17:53:54 +0200 (CEST)
Subject: Mark partial functions as such
In-Reply-To:
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
<8FAC7383-B509-464A-9009-5D7C8C355538@cs.brynmawr.edu>
<5B89606F.3010000@exmail.nottingham.ac.uk>
Message-ID:
On Fri, 31 Aug 2018, Ryan Trinkle wrote:
> This is probably not really for the libraries list, but in the same vein
> as this discussion, I think it would be extremely helpful to have a way
> of banning functions that does *not* require changing the upstream
> library. I would be thrilled to have a machine-checked ban on use of
> the 'head', 'tail', etc.
So far I have HLint rules to ban them. Unfortunately, they do not work
transitively. People have already proposed a TotalHaskell pragma
analogously to SafeHaskell.
From tikhon at jelv.is Fri Aug 31 16:21:15 2018
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Fri, 31 Aug 2018 18:21:15 +0200
Subject: Mark partial functions as such
In-Reply-To:
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
<8FAC7383-B509-464A-9009-5D7C8C355538@cs.brynmawr.edu>
<5B89606F.3010000@exmail.nottingham.ac.uk>
Message-ID:
Deeper questions of partiality aside, if a function can throw exceptions,
the documentation should spell this out *explicitly*, ideally also
specifying what the type of the exception may be. To me, this is a
*minimum* standard to expect from documentation in any language with
exceptions.
Whenever I write a function that might error out in my work code, I always
write a separate paragraph explaining this. Usually it reads something like
"Raises an error if these conditions aren't met" for whatever preconditions
the function has. I don't know if this documentation requirement is in our
style guide, but if it isn't I should put it in :).
This is definitely something we should have in the documentation for base.
I would document head something like this:
> Return the first element of the given list.
> Raises an 'ErrorCall' exception if the list is empty.
I could see a case for putting less emphasis on the fact that it's a
specific exception—exceptions in pure functions are a bit weird—but the
basic structure would still be the same: a distinct part of the
documentation calling out the error condition explicitly.
On Fri, Aug 31, 2018, 17:54 Henning Thielemann <
lemming at henning-thielemann.de> wrote:
>
> On Fri, 31 Aug 2018, Ryan Trinkle wrote:
>
> > This is probably not really for the libraries list, but in the same vein
> > as this discussion, I think it would be extremely helpful to have a way
> > of banning functions that does *not* require changing the upstream
> > library. I would be thrilled to have a machine-checked ban on use of
> > the 'head', 'tail', etc.
>
> So far I have HLint rules to ban them. Unfortunately, they do not work
> transitively. People have already proposed a TotalHaskell pragma
> analogously to SafeHaskell._______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ollie at ocharles.org.uk Fri Aug 31 16:59:59 2018
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Fri, 31 Aug 2018 17:59:59 +0100
Subject: Mark partial functions as such
In-Reply-To:
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
<8FAC7383-B509-464A-9009-5D7C8C355538@cs.brynmawr.edu>
<5B89606F.3010000@exmail.nottingham.ac.uk>
Message-ID:
On Fri, Aug 31, 2018 at 5:21 PM Tikhon Jelvis wrote:
> Deeper questions of partiality aside, if a function can throw exceptions, the documentation should spell this out *explicitly*, ideally also specifying what the type of the exception may be. To me, this is a *minimum* standard to expect from documentation in any language with exceptions.
Is this to be applied transitively? It has to be, to meet your
criteria, but this is a fairly unrealistic expectation to put on
library authors. If it's not applied transitively, then the
documentation creates a false sense of security - "catch these
exceptions that *I* throw and you're good!". I really think this part
of exceptions is a tooling problem that we have to solve. Haddock
should be responsible for figuring this out.
Ollie
From lemming at henning-thielemann.de Fri Aug 31 17:04:25 2018
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri, 31 Aug 2018 19:04:25 +0200 (CEST)
Subject: Mark partial functions as such
In-Reply-To:
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
<8FAC7383-B509-464A-9009-5D7C8C355538@cs.brynmawr.edu>
<5B89606F.3010000@exmail.nottingham.ac.uk>
Message-ID:
On Fri, 31 Aug 2018, Oliver Charles wrote:
> On Fri, Aug 31, 2018 at 5:21 PM Tikhon Jelvis wrote:
>
>> Deeper questions of partiality aside, if a function can throw
>> exceptions, the documentation should spell this out *explicitly*,
>> ideally also specifying what the type of the exception may be. To me,
>> this is a *minimum* standard to expect from documentation in any
>> language with exceptions.
'error' is not an exception, it is an undefined value. 'error' is only a
debugging convenience that would otherwise be an infinite loop. It should
not be necessary to distinguish them in production code.
From spam at scientician.net Fri Aug 31 17:06:43 2018
From: spam at scientician.net (Bardur Arantsson)
Date: Fri, 31 Aug 2018 19:06:43 +0200
Subject: Mark partial functions as such
In-Reply-To:
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
<8FAC7383-B509-464A-9009-5D7C8C355538@cs.brynmawr.edu>
<5B89606F.3010000@exmail.nottingham.ac.uk>
Message-ID:
On 31/08/2018 18.59, Oliver Charles wrote:
> On Fri, Aug 31, 2018 at 5:21 PM Tikhon Jelvis wrote:
>
>> Deeper questions of partiality aside, if a function can throw exceptions, the documentation should spell this out *explicitly*, ideally also specifying what the type of the exception may be. To me, this is a *minimum* standard to expect from documentation in any language with exceptions.
>
> Is this to be applied transitively? It has to be, to meet your
> criteria, but this is a fairly unrealistic expectation to put on
> library authors. If it's not applied transitively, then the
> documentation creates a false sense of security - "catch these
> exceptions that *I* throw and you're good!". I really think this part
> of exceptions is a tooling problem that we have to solve. Haddock
> should be responsible for figuring this out.
>
Not to mention the issues of "may throw" declarations for higher-order
functions... (Java checked exceptions are basically broken[1] because of
this. Well, this + the variance issues arising from inheritance and
method signatures, but obviously Haskell doesn't have inheritance, so...)
Regards,
[1] They even break "catch" because everybody is forced to wrap
"checked" exceptions in a RuntimeException if signatures don't specify
"may throw anything", so you *also* have to check for wrapped exceptions
in "catch" clauses. Anyway...
From tikhon at jelv.is Fri Aug 31 19:14:56 2018
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Fri, 31 Aug 2018 21:14:56 +0200
Subject: Mark partial functions as such
In-Reply-To:
References: <64929A3E-F090-4E3A-865E-1AF46E023529@cs.brynmawr.edu>
<8FAC7383-B509-464A-9009-5D7C8C355538@cs.brynmawr.edu>
<5B89606F.3010000@exmail.nottingham.ac.uk>
Message-ID:
This is a question of documentation, not type design. You don't have to
consider what exceptions your transitive dependencies might throw—you need
to understand what inputs *do* cause your function to fail. If you use head
in a safe way or have a call to error in an unreachable case, you shouldn't
say anything. On the other hand, if your function fails when the inputs
aren't relatively prime, you should document this regardless of whether the
failure is an exception you throw explicitly, a result of a partial pattern
match or a division by zero four layers of indirection away.
I definitely expect the author of a function to understand what inputs
cause that function to fail. If you don't understand this, you simply don't
understand the code you wrote. (Luckily, QuickCheck will probably find any
edge cases you missed when writing the function.)
Thinking about it a bit more, there's nothing specific to exceptions here.
If your code loops forever when the lengths of the inputs sum to a multiple
of seven, that's pretty handy to know from the documentation!
I would also expect the same style of documentation even for errors
expressed in the types with whatever your favorite generalization of Either
happens to be.
On Fri, Aug 31, 2018, 19:07 Bardur Arantsson wrote:
> On 31/08/2018 18.59, Oliver Charles wrote:
> > On Fri, Aug 31, 2018 at 5:21 PM Tikhon Jelvis wrote:
> >
> >> Deeper questions of partiality aside, if a function can throw
> exceptions, the documentation should spell this out *explicitly*, ideally
> also specifying what the type of the exception may be. To me, this is a
> *minimum* standard to expect from documentation in any language with
> exceptions.
> >
> > Is this to be applied transitively? It has to be, to meet your
> > criteria, but this is a fairly unrealistic expectation to put on
> > library authors. If it's not applied transitively, then the
> > documentation creates a false sense of security - "catch these
> > exceptions that *I* throw and you're good!". I really think this part
> > of exceptions is a tooling problem that we have to solve. Haddock
> > should be responsible for figuring this out.
> >
>
> Not to mention the issues of "may throw" declarations for higher-order
> functions... (Java checked exceptions are basically broken[1] because of
> this. Well, this + the variance issues arising from inheritance and
> method signatures, but obviously Haskell doesn't have inheritance, so...)
>
> Regards,
>
> [1] They even break "catch" because everybody is forced to wrap
> "checked" exceptions in a RuntimeException if signatures don't specify
> "may throw anything", so you *also* have to check for wrapped exceptions
> in "catch" clauses. Anyway...
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: