POPLing today. Let's discuss on Monday
| -----Original Message----- | From: [email protected] [mailto:[email protected]] | On Behalf Of Joachim Breitner | Sent: 11 July 2013 15:25 | To: [email protected] | Subject: Re: Exposing newtype coercions to Haskell | | Hi, | | despite my issues with recursive data types, I continued with the | implementation. | | I now added the check if the data type arguments can safely be coerced. | I do not scan what is in scope for NT values to use, but rather expect | the progammer to promise the required witness when he uses "deriving" | and the plug the functions together by himself: | https://github.com/nomeata/nt-coerce/blob/ec9b5/tests/LiftAbstract.hs | | I also added a test suite to show what works already: | https://github.com/nomeata/nt-coerce/tree/master/tests | what does rightfully not work, due to abstraction: | https://github.com/nomeata/nt-coerce/tree/master/tests/failing | and what does not yet work, although it conceivably should: | https://github.com/nomeata/nt-coerce/tree/master/tests/todo | | The test suite contains expected output in *.out and *.err, so you can | check out what happens without having to run it. The error messages are | not yet as nice as they should be. | | How to proceed from here Is this approach and design good enough to to | into GHC, despite not being able to handle _all_ cases where it | conceivably could, and the slight unwieldiness when coerctions for data | types based on abstract data types? | | BTW, I find it quite nice to be able to develop such a feature without | touching GHC’s source. If that is possible for more contributions, the | entry barrier to GHC would be noticeably lowered. | | Thanks, | Joachim | | | -- | Joachim “nomeata” Breitner | [email protected] • http://www.joachim-breitner.de/ | Jabber: [email protected] • GPG-Key: 0x4743206C | Debian Developer: [email protected] _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
