Records in Haskell

[AntC]

Isaac Dupree <ml <at> isaac.cedarswampstudios.org> writes:

> 
> In the meantime, I had an idea (that could work with SORF or DORF) :
> 
> data Foo = Foo { name :: String } deriving (SharedFields)
> 
> The effect is: without that "deriving", the declaration behaves just 
> like H98.
> 
> (For super flexibility, allow to specify which fields are shared,
> like "deriving(SharedFields(name, etc, etc))" perhaps.)
> 
> Is it too verbose? Or too terrible that it isn't a real class (well, 
> there's Has...)?
> 
> -Isaac
> 
Thanks Isaac, hmm: that proposal would work against what DORF is trying to do.

You're right about the `deriving` syntax currently being used for classes. The 
fact of re-purposing the surface syntax is really no different to introducing 
different syntax.

Apart from that, it might work for SORF -- and fall into exactly what I don't 
like about SORF, which is that it sabotages the namespace/module control that 
applies for every other user-defined name in Haskell.

What you're not getting is that DORF quite intentionally helps you hide the 
field names if you don't want your client to break your abstraction.

So under your proposal, a malicious client could guess at the fieldnames in 
your abstraction, then create their own record with those fieldnames as 
SharedFields, and then be able to update your precious hidden record type.

And guessing the fieldnames is dead easy if you've exported the field selector 
function, to allow read-only access -- or so you thought.

Under DORF, despite the client guessing the fieldnames, they can't use them at 
all if you don't export them -- because they're in a sealed-off namespace, 
just like regular Haskell.

AntC