Removing MonadFail from Monad

Roman Cheplyaka roma at ro-che.info
Tue Dec 17 10:06:03 UTC 2013


* Andreas Abel <andreas.abel at ifi.lmu.de> [2013-12-17 10:53:21+0100]
> On 17.12.2013 00:32, Roman Cheplyaka wrote:
> >* David Luposchainsky <dluposchainsky at googlemail.com> [2013-12-16 23:57:19+0100]
> >>>I don't understand the restriction "is defined via data" since I am not
> >>>aware of defining constructors outside of data or with something other
> >>>than the data keyword.  Please clarify.
> >>
> >>I meant "data and not newtype". If "Only" is a newtype data constructor,
> >>the pattern is irrefutable by design, is it not?
> >
> >One notable case of one-constructor types defined not via data is
> >tuples. You certainly don't want warnings for that!
> 
> Should not tuple types be understood as
> 
>   data (,) a b = (,) a b
>   data (,,) a b c = (,,) a b c
> 
> making them one-constructor types?!

You may think of it this way. But for the purposes of this proposal,
tuples shouldn't be treated like data types, because there's no
possibility they will every be extended with more constructors.

> >Regarding newtypes vs data, I'm not so sure it should make a difference.
> >It's customary to make one-field types newtypes, and then, if one
> >realizes that more fields are needed, turn them into proper data types.
> 
> I agree.  What operational semantics is concerned (this mean the
> execution model of Haskell in the programmer's mind),
> 
>   newtype = data

Not really. There's a semantic difference (both in operational and
denotational semantics) — see http://www.haskell.org/haskellwiki/Newtype

Not that this is relevant for this discussion.

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131217/1864a464/attachment.sig>


More information about the Libraries mailing list