On 12/28/11 1:34 PM, Donn Cave wrote:
Quoth Greg Weber<g...@gregweber.info>,
On Wed, Dec 28, 2011 at 2:12 PM, Donn Cave<d...@avvanta.com> wrote:
...
I would think row polymorphism is a must-have.
Perhaps if you want *extensible* records. If you would like to make some
progress with records in the near future rather than keeping records in
limbo, I think we really need to give up for the moment on any higher form
of abstraction than straight-forward name-spacing.
No, to be clear on that, I haven't given much thought to extensibility
per se, I was thinking row polymorphism is a valuable feature on its own,
and extensibility just seemed to me to be an implicit side benefit.
Yes, row polymorphism would still be helpful in lack of extensible
records. In particular it allows for easily determining principle
(structural) types of records; this is desirable from a generic
programming perspective even if records on the whole are not
structurally typed.
That is, we can distinguish the following types
data Foo = MkFoo { x :: T }
data Bar = MkBar { x :: T }
By considering them to desugar into
type Foo = { __type :: Foo , x :: T }
constructor MkFoo :: T -> Foo
pattern MkFoo :: T -> Pattern
type Bar = { __type :: Bar , x :: T }
constructor MkBar :: T -> Bar
pattern MkBar :: T -> Pattern
accessor x :: { x :: T , ... } -> x
Of course, an actual implementation needn't come up with a phantom
argument like __type in order to nominally distinguish structurally
identical types. Rather, the existence of the hack shows that it's doable.
--
Live well,
~wren
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
