Benjamin Franksen wrote:
Well, not quite true, because the type of the label is used to index theWell at the moment this would give an error, but remember the list is heterogeneous, so you can just not give the list a type, and simply append the specific function... admitedly this is not as type-safe.
hUpdateAtLabel field2 someFunction myRecord
That is an advantage of hLists as compared to normal records.
A disadvantage is that each field access needs to traverse the list. I wonder if this isn't rather less efficient than the random access provided by normal records.
value, the selection happens at compile time. So at run time there is no
instance selection left... it is simply the value. At least in theory! whether
the particular compiler/interpreter does this is implementation dependant.
This is why we decided that the simpler to implement list was better than
a more complex tree structure.
Automatic wrapping is easy. What is not so easy and I think not even possible, is automatic _un_wrapping, so that the wrapping isn't exposed at all to the programmer.
One way to do this is to replace the type with a pair:
data Wrap a = Wrap {unwrapA :: a}wrap a = (unwrapA,Wrap a)
so to unwrap do:
unwrap a = (fst a) (snd a)
But without working through an example it is difficault to see how this would work with the template-haskell.
I am not a type system guru, so can anyone enlighten me on why higher ranked types are not allowed in instances? Is there a principle problem, or is it just difficult to implement? Does this have to do with this "higher order unification" that Haskell is alleged not to have?
No idea, but it sounds like a good idea. I suspect this has to do with the definition of type-equality/unification used to match instances.
Keean. _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
