AntC | 18 Jul 12:33 2013
Picon

Why are field selectors functions? [was: ghc-users A possible alternative to dot notation for record access]

No! This isn't more bikeshedding about notation.

It's a bit of Haskell archaeology.

> On Sun, Jun 30, 2013 at 2:59 AM, Judah Jacobson wrote:
[This isn't exactly what Judah wrote.]
> ...
>
> Instead of `x f` (to access field x of record f),
> maybe we could write `f{x}` as the record selection.  
>

The more I thought about that ...

We use { ... } to declare records, build them, update them.
We use { ... } in pattern matching to access named fields.

Why don't we use { ... } to access named fields in terms?

The syntax `e{ foo }` is unused in H98. (Or at least it was in 1998.)
Can someone who was there at the time (1994?, TRex?)
remember if that was ever considered?

In the declaration, the build/update, and pattern match:

    data R = MkR { foo :: Int }
    r = MkR { foo = 7 }
    \ (MkFoo { foo }) -> ...      -- using NamedFieldPuns

`foo` is clearly bound to an Int.
(Continue reading)

Jon Fairbairn | 8 Aug 11:26 2013
X-Face
Picon
Picon

Re: Why are field selectors functions?

AntC <anthony_clayden <at> clear.net.nz> writes:

> No! This isn't more bikeshedding about notation.
>
> It's a bit of Haskell archaeology.
>
>> On Sun, Jun 30, 2013 at 2:59 AM, Judah Jacobson wrote:
> [This isn't exactly what Judah wrote.]
>> ...
>>
>> Instead of `x f` (to access field x of record f),
>> maybe we could write `f{x}` as the record selection.  
>>
>
> The more I thought about that ...
>
> We use { ... } to declare records, build them, update them.
> We use { ... } in pattern matching to access named fields.
>
> Why don't we use { ... } to access named fields in terms?
>
> The syntax `e{ foo }` is unused in H98. (Or at least it was in 1998.)
> Can someone who was there at the time (1994?, TRex?)
> remember if that was ever considered?

No one else has answered (at least in café), but perhaps the
reason is that like me they can’t really remember! I do remember
that since Haskell is a functional language we wanted as many
things to be functions as possible; we did want to be able to
pass field selectors around as arguments to other functions.
(Continue reading)

David Banas | 9 Aug 15:49 2013
Picon

Re: Why are field selectors functions?

Wouldn't the implementation hiding feature of the newtype idiom be broken, if field selectors were not first class functions? For instance, the following code (taken shamelessly from Ch. 10 of Real World Haskell):

module Parse (
    runParser
) where

data ParseState = ParseState {
    string :: String
} deriving (Show)

newtype Parser a = Parser {
    runParser :: ParseState -> Either String (a, ParseState)
}

has the attractive feature of hiding the internal implementation of the ParseState and Parser types from the user, preventing him from, for instance, pattern matching on either and thus writing code, which may break when we change the implementation. I believe this is only possible, because the runParser accessor is exportable as a first class function.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Gmane