Re: [Haskell-cafe] Why are field selectors functions?

2013-08-09 Thread David Banas
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@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Why are field selectors functions?

2013-08-08 Thread Jon Fairbairn
AntC anthony_clay...@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.

I vaguely remember suggesting some years later that we should
have {…} being a function, so that {field} is a field selector
and {field=value} is a field setter (and requiring that you had
to write use normal function application: “{field} structure” to
select field from structure). SimonPJ gave a reason why not, and
I’m sure it will be possible to search out what he said.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe