Records (was Re: [Haskell] Improvements to GHC)

[Georg Martius]

Hi folks,

rather than discussing about which operator symbol to use for record access, 
which is really a question of personal taste we should try to seriously 
discuss the proposals and get to a solutions! 

We all seem to agree that records are broken in Haskell. In order to fix that 
we need a new and most probably incompatible solution. However, I think the 
new solution should go in a new version of the Haskell standard (among other 
things :-) ). 
I would strongly disadvice to try to stick with the old system and improve it.
Just because there are lots of different opinions we should still try to find 
a reasonable solution soon.

Desite the minor problem of '.' that dominated the discussion so far, what are  
the REAL offences against Simons proposal [1] (denoted as SR in the 
following)? 
To me it sounds like a very reasonable starting point. 
Which other proposals exist?

I quote David Roundy's list of problems [2] with a short annotation whether SR 
solves them:

1. The field namespace issue.
	solved by not sharing the same namespace with functions 
2. Multi-constructor getters, ideally as a function.
	not solved. only possible by hand
	- As stated by Wolfgang Jeltsch [3]  another datatype design might be better
	- I can image a solution is within SR example:
>	 data Decl = DeclType { name :: String, ... }
>                          | DeclData { name :: String, ... }
>                          | ...
>	d :: Decl 
in addition to 
>	d.DeclType.name 
>	d.DeclData.name 
we provide (only if save, see 3.)
>	d.name 

3. "Safe" getters for multi-constructor data types.
	not supported as it is
	- with the above suggestion it could be possible (don't know if desireable)

4. Getters for multiple data types with a common field.
	- solved with contrains 
	>  getx :: (r <: { x :: a }) => r -> a

5. Setters as functions.
	doesn't seem to be supported, or I don't see it right now.

6. Anonymous records.
	Supported

7. Unordered records.
	I don' t understand it. 

points added from me:
8. Subtyping
	Supported, quite nicely

9. higher order versions for selecting, updateing ... [4]
	not supported
	seems important to me, any solutions?

Regards 
	Georg	

[1] http://research.microsoft.com/~simonpj/Haskell/records.html
[2] http://www.haskell.org//pipermail/haskell-cafe/2005-November/012226.html
[3] http://www.haskell.org//pipermail/haskell-cafe/2005-November/012227.html
[4] http://www.haskell.org//pipermail/haskell-cafe/2005-November/012162.html

Am Donnerstag, 17. November 2005 19:08 schrieb Dimitry Golubovsky:
> Sebastian Sylvan wrote:
> >Personally I think that the dot is way to good of a symbol to be
> >"wasted" on function composition. I mean, how often do you really use
> >function composition in a way which doesn't obfuscate your code? I use
> >($) way more often than (.). Some people do use it more often than I
>
> I found it useful to use (mainly for debugging purposes)
>
> mapM (putStrLn . show) <some list>
>
> if I want to print its elements each on a new line.
>
> --
> Dimitry Golubovsky
>
> Anywhere on the Web

-- 
---- Georg Martius,  Tel: (+49 34297) 89434 ----
------- http://www.flexman.homeip.net ---------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.haskell.org//pipermail/haskell/attachments/20051120/141e1341/attachment-0001.bin