Newtype wrappers

Joachim Breitner mail at joachim-breitner.de
Tue Jan 15 10:03:33 CET 2013


Hi,

Am Montag, den 14.01.2013, 18:09 +0000 schrieb Simon Peyton-Jones:
> I’d appreciate
> 
> ·        A sense of whether you care. Does this matter?
> ·        Improvements to the design I propose

I do care (but that is no news, given my pestering on #2110 :-)) and
obviously I am happy that things are moving.

What I am still missing here is a way for a container library writer to
say:
        "map Age" may be compiled to a noop if foo is known to be a
        newtype constructor or deconstructor
        
With the current proposal, the _user_ of a library has to 
 * know that types Age and Int are actually equivalent
 * introduce and give a name to the [Age] -> [Int] wrapper
 * use it wherever "map Age" is used

The last step can probably replaced by a RULE. But note that all three
steps are a burden on the _user_ of the newtype and the container type
(which most likely come from different libraries). Also, the first step
is a clear breach of abstraction: The user should not have to know
whether Age is a newtype or not, at least not until he wants to actively
work on performance problems, and even then code should not break if a
library switches from newtype to data.

Maybe it is possible to implement this it on top of the current
proposal: How can the author of a container tell the compiler that "map
Foo" or "map unFoo" are safe to be replaced by coercions.

One might argue that this yields unpredictable performance. But it is no
different than other successful tools like list fusion: There, as well,
only the authors of different components need to set up the
corresponding RULES. The user can combine independently developed
functions and they will possibly fuse. And the user does not really know
when and where fusion happens, or what list fusion is, but he knows that
generally, good things happen (just as he expects newtypes to be
generally free) and if he needs to know more, he’ll have to read the
core.

But maybe what I am looking for is not a language feature but a core
compiler pass, analyzing the actual code of functions like map and
discovering that "map Age = [AgeNTC]" is a safe rule.

Greetings,
Joachim


-- 
Joachim "nomeata" Breitner
  mail at joachim-breitner.de  |  nomeata at debian.org  |  GPG: 0x4743206C
  xmpp: nomeata at joachim-breitner.de | http://www.joachim-breitner.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20130115/dc8faaf1/attachment.pgp>


More information about the Glasgow-haskell-users mailing list