<div>On Wed, Dec 28, 2011 at 2:12 PM, Donn Cave <span dir="ltr"><<a href="mailto:donn@avvanta.com">donn@avvanta.com</a>></span> wrote:</div><div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Quoth Greg Weber <<a href="mailto:greg@gregweber.info">greg@gregweber.info</a>>,<br>
...<br>
<div class="im">> Many of the built-in record proposals seem more ambitious (create a new<br>
> record from an existing one, generalize in some other direction). More<br>
> power or generalization could be very useful, but it can wait for later -<br>
> Haskell's records are glaringly bad because they lack name-spacing.<br>
><br>
> I think one of the problems being faced with improving records is a false<br>
> choice between a quick but hacky library desugaring or a major "Extensible"<br>
> records built into the compiler. What I am proposing is that (unless<br>
> someone proposes a great desugaring solution) we make it the immediate goal<br>
> to have records built into the compiler, but done in the simplest (perhaps<br>
> least "Extensible") way that just accomplishes name-spacing.<br>
<br>
</div>It's sure easy to imagine something like that happening, in principle,<br>
but ... are you saying that extensibility specifically has been a major<br>
issue? Could be, I haven't been paying so much attention.<br></blockquote><div><br></div><div>Yes, I believe it is common knowledge and stated in many places that the community cannot decide on the best *extensible* record system.</div>
<div><a href="http://www.haskell.org/haskellwiki/GHC:FAQ#Extensible_Records">http://www.haskell.org/haskellwiki/GHC:FAQ#Extensible_Records</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Wouldn't extensibility more or less come along with row polymorphism?<br>
I mean, my understanding of the term is that an expression that<br>
instantiates a particular record field, can incorporate a record lacking<br>
that field, which seems to me to be implicit in row polymorphism anyway.<br>
I would think row polymorphism is a must-have.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If you're interested in looking at old, Haskell-related record systems,<br>
also see O'Haskell.<br></blockquote><div><br></div><div>I am interested in any potential solution. You could link to it on the ExtensibleRecords wiki page and explain it a bit for future reference. O'Haskell seems to be very much concerned with being as extensible as possible - to the point of trying to do OO in Haskell.</div>
<div><br></div><div>Greg Weber</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<font color="#888888"><br>
Donn<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
Glasgow-haskell-users mailing list<br>
<a href="mailto:Glasgow-haskell-users@haskell.org">Glasgow-haskell-users@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/glasgow-haskell-users" target="_blank">http://www.haskell.org/mailman/listinfo/glasgow-haskell-users</a><br>
</div></div></blockquote></div><br></div></div>