[Haskell-cafe] Re: Keeping an indexed collection of values?
Job Vranish
jvranish at gmail.com
Fri Aug 21 14:17:52 EDT 2009
It only requires type annotations on your uses of empty (as that is the only
way to construct a collection). The phantom type sticks to everything after
that.
If you don't care to add a signature then things still work just fine, you
just won't be prevented from using indexes from the wrong collection if the
the collection type is the same. I think this is nice, because if you are
working with just one collection, or collections of only different types you
probably don't want to care about the phantom type.
But if you do care, it adds extra protection.
For example:
data P1
data P2
to = runState
inCol = evalState
a = empty :: IndexedCollection Int P1
b = empty :: IndexedCollection Int P2
(i1, a') = add 5 `to` a
(i2, b') = add 16 `to` b
test = lookup i2 `inCol` a' -- type error, but type checks if no signatures
on a or b
- Job
On Fri, Aug 21, 2009 at 12:24 PM, Sebastian Fischer <
sebf at informatik.uni-kiel.de> wrote:
>
> On Aug 21, 2009, at 5:11 PM, Job Vranish wrote:
>
> I also added an extra phantom type parameter to the collection (and key)
>> so that I can prevent keys from being used on different collections even if
>> they hold elements of the same type.
>>
>
>
> I have the impression that this requires explicit type annotations with
> your current solution which seems a bit tiresome. If not instantiated to
> specific different types, the additional phantom types of different
> collections can just be unified which does not lead to a type error.
>
> As you seem to implement a monadic interface, you might be able to steal
> the idea of using higher-rank polymorphism (that is used in the ST monad
> implementation) to ensure that the phantom types of different collections
> cannot be unified. But that would probably mean to implement your own monad
> that carries this phantom type too..
>
> Cheers,
> Sebastian
>
>
> --
> Underestimating the novelty of the future is a time-honored tradition.
> (D.G.)
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090821/9a891407/attachment.html
More information about the Haskell-Cafe
mailing list