[vector] #83: PhaseChange class, Mutable data family

[vector]

#83: PhaseChange class, Mutable data family
------------------------+---------------------------------------------------
Reporter:  illissius    |        Owner:     
    Type:  enhancement  |       Status:  new
Priority:  minor        |    Milestone:     
 Version:               |   Resolution:     
Keywords:               |  
------------------------+---------------------------------------------------

Comment(by illissius):

 Hmm, you're right about thaw/unsafeThaw. I actually knew what unsafeThaw
 does and forgot to turn my brain on. Conceptually though, the difference
 between a full freeze/thaw and an unsafe one is a copy, and that makes me
 want to factor out the copy. One way to solve it, in thaw, would be to
 unsafeFreeze it back before returning the copy: would that badly affect
 performance? But if we do need different copys for the different types,
 making four methods, then we might as well just put freeze/thaw themselves
 in the class...

 ...and you're quite right that if there's no copy method, then a data
 family isn't strictly necessary and a type family can also work. The other
 reason I want a data family is that whenever I encounter the pattern:

 {{{
 type family Foo a
 data A = ...
 data FooA = ...
 type Foo A = FooA
 data B = ...
 data FooB = ...
 type Foo B = FooB
 ...
 }}}

 it makes me want cut out the middleman:

 {{{
 data family Foo a
 data A = ...
 data instance Foo A = ...
 data B = ...
 data instance Foo B = ...
 ...
 }}}

 which besides cutting down on boilerplate just feels so much cleaner, and
 has the added benefits that Foo and Foo A are real, first-class types that
 you can do the same things with that you could any other other type (for
 example: put it in an instance head), type inference is improved (because
 it's a real type), and you no longer need two different ways to refer to
 the same thing. The drawback, of course, is that it requires the instance
 types to depend on the family, instead of allowing the reverse direction.

 I think that even if you made no other changes, replacing

 {{{
 type family Mutable v :: * -> * -> *
 }}}

 with

 {{{
 data family Mutable v :: * -> * -> *
 forall Vector. type MVector = Mutable Vector
 }}}

 would be an improvement to vector, but of course not a backwards
 compatible one.

 Anyways, I'm getting convinced that since there's no way to reconcile the
 situation, and the Vector instances in my phasechange package aren't
 actually adding any value (they're mostly there for completeness), that
 the best choice for me is to part ways with those and along with them
 GHC's problematic unsafeFreeze/unsafeThaw primitives, and move over to the
 much simpler 'data family Mutable a' formulation.

 Thanks for the input!

 (Feel free to close.)

-- 
Ticket URL: <http://trac.haskell.org/vector/ticket/83#comment:2>
vector <http://trac.haskell.org/vector>
Package vector