role signatures in libraries

[John Lato]

Hi Richard,

Thanks for your response.


On Mon, Dec 2, 2013 at 12:00 PM, Richard Eisenberg <eir at cis.upenn.edu>wrote:

> Hi John,
>
> Good questions!
>
> On Nov 27, 2013, at 3:35 PM, John Lato wrote:
>
> Consider data V a = V Int (ForeignPtr a), a storable vector, where the Int
> is the number of elements.  We would then want to add 'type role V nominal'
> as the stored data depends on the Storable instance for the 'a' parameter.
> Is this correct?
>
>
> If you want to be fully safe in the presence of different Storable
> dictionaries for Age and Int, yes, you should declare `a` to be nominal.
> However, it's much more likely that Age and Int have the same
> implementation for Storable, and it might be much more convenient for your
> users to be able to freely convert between `V Age` and `V Int`. I would say
> that this is a judgment call -- nominal is safer (always), but
> representational may be more practical.
>

Although I can't think of any case where I've changed a Storable instance
across newtypes, Anthony makes use of this feature and others must also.  I
think the best thing to do is to make the best use of roles as we currently
have them, for the most safety we can get.  A no-cost conversion can always
be achieved by unsafeCoerce after all.


>
> Note that this is not an issue of type safety, per se. It's much more an
> issue of type class coherence across newtypes.
>

>
> To me it looks like a next step would be a way to specify that two
> representationally-equal types share a dictionary, and thus could be
> considered nominally equal for that dictionary. This would mean if we use
> newtype MkAge = MkAge Int deriving Storable (via
> GeneralizedNewtypeDeriving), we could then coerce V Int to V MkAge. We
> don't currently have a way to do this, correct?
>
> That's correct. Extending the roles mechanism in this direction might be a
> fruitful future direction, but it's not currently on my docket. I'm happy
> to advise if someone else wants to take this on!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131202/357fe711/attachment.html>