[Hugs-users] [haskell-beginners] Lifting over record syntax

Anthony Clayden anthony_clayden at clear.net.nz
Wed Oct 31 11:31:06 UTC 2018


musing on this
https://mail.haskell.org/pipermail/beginners/2018-October/018363.html

to which my reply talked mainly about Trex.

Does it make sense to regard a Trex record (or any free-standing
anonymous/extensible record) as a container, with values 'lifted' into the
structure, and an interface given by the label names, _not_ by order of
fields? That is, "container" in the Monad sense?

Does it further make sense if all the values are already lifted into some
Functor (like Maybe or (Either e) ) to hoist the Functor out over the
record structure?

I'm not sure I'm up with the program for Functor/Applicative/Monad
everywhere. If a record structure is a Functor, what's the type
constructor? `Rec`? If record structure is an Applicative, what's the
constructor for `pure` that lifts into `Rec`? The `<*>` aka `ap` or bind
for a Monad presumably is to take two records (with disjoint labels) and
concatenate them to a single record.

Given

data Person = Person (Rec( name :: String, age :: Int))

we want, corresponding to the question:

Person <?$>  (age = 27) <*> (name = "Joe")

in which operator <?$> is map-like: it takes a function to its left that
expects a record of n fields, then maps over n singleton records with
corresponding labels appearing in any order.

I might be able to get there by generics/reflection over the field names
embedded in data constructor `Person`s type, then overloading <?$> to look
for each label. That is, if Hugs had any sort of generics/TypeRep.

Label names in Trex are literals; there's no such thing as a label
variable. (Which is why it's a tad annoying that they start lower case.)
Furthermore the same label name must appear in both terms and types -- in
fact labels occupy a namespace separate vs terms or types. So Trex is a
long way from from generic record handling like:

recAppend :: ( rho'\__x ) => Rec rho' -> Rec ( __x :: a) -> Rec ( __x :: a
| rho')
recAppend rho ( __x = x ) = ( __x = x | rho )

in which I've used double-underscore prefix to signify a label variable.
This is intended to extend a record `rho` with a singleton record. If we
try appending a record with more than one field, beware that field order is
arbitrary, so this

recAppend rho ( __x = x, __y = y) = ...

has no principal type (a familiar difficulty). The programmer doesn't care
which way round labels `__x, __y` bind, providing they're distinct, but the
typing does care.

Some sort of generic record extend/concatenate would be great. You might,
looking at Trex syntax, think that `|` is it. This is valid:

( x = "x" | (y = 'y' | (z = 3.14)))
( x = "x", y = 'y', z = 3.14 )           -- equivalent

I could put any record value in place of `(z = 3.14)`. But not in place of
the `x = ..` or `y = ...`: `|` is not an operator, not commutative, not
associative. Furthermore this is a place where parentheses make a
difference, unlike usually in Haskell. So the following are not equivalent,
indeed they're all invalid syntax

( (x = "x") | (y = 'y' | (z = 3.14)))       -- x = ... has parens
( x = "x"  | (y = 'y' | z = 3.14 ))          -- z = ... doesn't have parens
( x = "x" | y = 'y' | (z = 3.14) )           -- z = ... in parens OK, but y
= ... is not
( (x = "x") | (y = 'y') | (z = 3.14) )      -- no chance

I'd like to write term `( rho1 | rho2 )` to concatenate two records. That's
currently unrecognised syntax, so I think could be added as such. What
would be its type/is it principal?

( rho1 | rho2 ) :: (rho1' \\ rho2') => Rec( rho1' | rho2' )    -- inventing
more syntax

in which constraint `(rho1' \\ rho2')` requires the two rows' labels be
mutually disjoint -- read "lacks all". Ur/web has something like this. Note
I'm not envisaging `|` as a genuine operator: this is still hard-wired
syntax; pipe is a reserved symbol in H98 anyway.


AntC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/hugs-users/attachments/20181101/a2248477/attachment.html>


More information about the Hugs-Users mailing list