Frege has a detailed explanation of the semantics of its record implementation, and the language is *very* similar to Haskell. Lets just start by using Frege's document as the proposal. We can start a new wiki page as discussions are needed.
If it's a serious proposal, it needs a page to specify the design. Currently all we have is a paragraph on http://hackage.haskell.org/trac/ghc/wiki/Records, under "Better name spacing".
As previously stated on this thread, the Frege user manual is available here:
http://code.google.com/p/frege/downloads/detail?name=Language-202.pdf
see Sections 3.2 (primary expressions) and 4.2.1 (Algebraic Data type Declaration - Constructors with labeled fields)
To all those concerned about Records: look at the Frege implementation and poke holes in it.
Well the most obvious issue is this. 3.2 says
e.m = (T.m e) if the expression e has type t and the type constructor
of t is T and there exists a function T.m
But that innocent-looking statement begs the *entire* question! How do we know if "e has type t? This is the route ML takes for arithmetic operators: + means integer plus if the argument is of type Int, float plus if the argument is of type Float, and so on.
Haskell type classes were specifically designed to address this situation. And if you apply type classes to the record situation, I think you end up with
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
Well, so maybe we can give up on that. Imagine Frege without the above abbreviation. The basic idea is that field names are rendered unique by pre-pending the module name. As I understand it, to record selection one would then be forced to write (T.m e), to select the 'm' field. That is the, qualification with T is compulsory. The trouble with this is that it's *already* possible; simply define suitably named fields
data T = MkE { t_m :: Int, t_n :: Bool }
Here I have prefixed with a (lower case version of) the type name. So we don't seem to be much further ahead.
Maybe one could make it optional if there is no ambiguity, much like Haskell's existing qualified names. But there is considerable ambiguity about whether T.m means
m imported from module T
or
the m record selector of data type T
Perhaps one could make it work out. But before we can talk about it we need to see a design. Which takes us back to the question of leadership.
Simon
We only want critiques about
* achieving name-spacing right now
* implementing it in such a way that extensible records could be implemented in its place in the future, although we will not allow that discussion to hold up a records implementation now, just possibly modify things slightly.
Greg Weber
On Thu, Dec 29, 2011 at 2:00 PM, Simon Peyton-Jones