Proposal to deprecate and then drop fromJust

Joachim Breitner mail at joachim-breitner.de
Tue Feb 24 10:30:33 UTC 2015


Hi,

Am Dienstag, den 24.02.2015, 02:23 -0800 schrieb Erik de Castro Lopo:
> > -1
> > 
> > If it wasn’t there, I probably would not vote for adding it, but in the
> > interest of general stability, I believe removing this function is not
> > worth the effort.
> 
> I think its interesting (I've heard this from a couple of people) that 
> if this function was up for *addition* it would be rejected, but they do
> not support its removal or even deprecation.

Every change has its cost, addition and removal, and stability is a
useful goal of its own. So if the benefits are not convincing, the
change should not happen.

Clearly if we would design the Haskell libraries from the ground up, we
would do a _lot_ of things differently, wouldn’t we?

I think deprecation should be used for things that are going to be
removed, hence I’m not in favor or deprecating it either.

> Possibly what we need is a pragma to mark functions partial and a warning
> flag that warns on usage of functions that have been marked partial.

Right, see my other mail where I propose the same thing :-)
I find hat a very good way forward and would be willing to guide anyone
who wants to implement that in GHC.

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.dehttp://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150224/22bbd5d6/attachment.sig>


More information about the Libraries mailing list