Re: Posting etiquette, was Re: Records in Haskell

Hi, One could also argue that a good email client should automatically hide long quotes. In fact, I guess many people are not even aware of the problem because their client does this. Cheers, Pedro On Thu, Jan 19, 2012 at 11:14, Malcolm Wallace wrote:

Sorry to pick on your post in particular Matthew, but I have been seeing a lot of this on the Haskell lists lately.

I find it completely unreasonable for a reply to a very long post to quote the entire text, only to add a single line at the bottom (or worse, embedded in the middle somewhere). In this case, there are 7 pages of quotation before your one-sentence contribution. (That is on my laptop. I dread to think how many pages it represents on a smartphone screen...) Usually, if I need to scroll even to the second page-worth of quotation and have still not found any new text, I now just delete the post without reading it.

It is a failure to communicate well, on the part of the writer who values their own time more highly than that of their intended readers. Even the much-maligned top-posting style, as forced upon Outlook users (and as I am doing right here), is preferable to the failure to trim, or to get to the point quickly. My inbox has >1600 unread messages in it, and life is just too short. So I offer this plea as a constructive social suggestion - if you want your ideas to reach their intended audience, don't annoy them before they have even seen what you want to say.

Regards, Malcolm

On 15 Jan 2012, at 20:33, Matthew Farkas-Dyck wrote:

...

On 13/01/2012, Simon Peyton-Jones wrote:

...

Thanks to Greg for leading the records debate. I apologise that I don't have enough bandwidth to make more than an occasional contribution. Greg's new wiki page, and the discussion so far has clarified my thinking, and this message tries to express that new clarity. I put a conclusion at the end.

Simon

Overview ~~~~~~~~ It has become clear that there are two elements to pretty much all the proposals we have on the table. Suppose we have two types, 'S' and 'T', both with a field 'f', and you want to select field 'f' from a record 'r'. Somehow you have to disambiguate which 'f' you mean.

(Plan A) Disambiguate using qualified names. To select field f, say (S.f r) or (T.f r) respectively.

(Plan B) Disambiguate using types. This approach usually implies dot-notation. If (r::S), then (r.f) uses the 'f' from 'S', and similarly if (r::T).

Note that

* The Frege-derived records proposal (FDR), uses both (A) and (B) http://hackage.haskell.org/trac/ghc/wiki/Records/NameSpacing

* The Simple Overloaded Record Fields (SORF) proposal uses only (B)

http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields

...

* The Type Directed Name Resolution proposal (TDNR) uses only (B)

http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolutio...

...

I know of no proposal that advocates only (A). It seems that we are

agreed

...

that we must make use of types to disambigute common cases.

Complexities of (Plan B) ~~~~~~~~~~~~~~~~~~~~~~~~ Proposal (Plan B) sounds innocent enough. But I promise you, it isn't. There has ben some mention of the "left-to-right" bias of Frege type inference engine; indeed the wohle explanation of which programs are accepted and which are rejected, inherently involves an understanding of the type inference algorithm. This is a Very Bad Thing when the type inference algorithm gets complicated, and GHC's is certainly complicated.

Here's an example:

type family F a b data instance F Int [a] = Mk { f :: Int }

g :: F Int b -> () h :: F a [Bool] -> ()

k x = (g x, x.f, h x)

Consider type inference on k. Initially we know nothing about the type of x. * From the application (g x) we learn that x's type has shape (F Int <something>). * From the application (h x) we learn that x's type has shape (F <something else> [Bool]) * Hence x's type must be (F Int [Bool]) * And hence, using the data family we can see which field f is intended.

Notice that a) Neither left to right nor right to left would suffice b) There is significant interaction with type/data families (and I can give you more examples with classes and GADTs) c) In passing we note that it is totally unclear how (Plan A) would deal with data families

This looks like a swamp. In a simple Hindley-Milner typed language you might get away with some informal heuristics, but Haskell is far too complicated.

Fortunately we know exactly what to do; it is described in some detail in our paper "Modular type inference with local assumptions" http://www.haskell.org/haskellwiki/Simonpj/Talk:OutsideIn

The trick is to *defer* all these decisions by generating *type constraints* and solving them later. We express it like this:

G, r:t1 |- r.f : t2, (Has t1 "f" t2)

This says that if r is in scope with type t1, then (r.f) has type t2, plus the constraint (Has t1 "f" t2), which we read as saying

Type t1 must have a field "f" of type t2

We gather up all the constraints and solve them. In solving them we may figure out t1 from some *other* constraint (to the left or right, it's immaterial. That allow us to solve *this* constraint.

So it's all quite simple, uniform, and beautiful. It'll fit right into GHC's type-constraint solver.

But note what has happened: we have simply re-invented SORF. So the conclusion is this:

the only sensible way to implement FDR is using SORF.

What about overloading? ~~~~~~~~~~~~~~~~~~~~~~~ A feature of SORF is that you can write functions like this

k :: Has r "f" Int => r -> Int k r = r.f + 1

Function 'k' works on any record that has a field 'f'. This may be cool, but it wasn't part of our original goal. And indeed neither FDR nor TDNR offer it.

But, the Has constraints MUST exist, in full glory, in the constraint solver. The only question is whether you can *abstract* over them. Imagine having a Num class that you could not abstract over. So you could write

k1 x = x + x :: Float k2 x = x + x :: Integer k3 x = x + x :: Int

using the same '+' every time, which generates a Num constraint. The type signature fixes the type to Float, Integer, Int respectively, and tells you which '+' to use. And that is exactly what ML does!

But Haskell doesn't. The Coolest Thing about Haskell is that you get to *abstract* over those Num constraints, so you can write

k :: Num a => a -> a k x = x + x

and now it works over *any* Num type.

On reflection, it would be absurd not to do ths same thing for Has constraints. If we are forced to have Has constraints internally, it woudl be criminal not to abstract over them. And that is precisely what SORF is.

Is (Plan A) worth it? ~~~~~~~~~~~~~~~~

Once you have (Plan B), and SORF in full glory, plus of course the existing ability to name fields T_f, S_f, if you want, I think it is highly questionable whether we need the additional complexities of (Plan A)?

And I do think (Plan A) has lots of additional complexities that we have not begun to explore yet. The data-family thing above is an example, and I can think of some others.

But even if it was simple, we still have to ask: does *any* additional complexity give enough payoff, if you already have SORF? I suspect not.

Extensions to SORF ~~~~~~~~~~~~~~~~~~ Frege lets you add "virtual fields" to a record type, using an extra RExtension mechanism that I do not yet understand. But SORF lets you do so with no additional mechanism. See "Virtual record selectors" on http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields The point is that the existing type-class instance mechanisms do just what we want.

Syntax ~~~~~~ The debate on the mailing list has moved sharply towards discussing lexical syntax. I'm not going to engage in that discussion because while it is useful to air opinions, it's very hard to get agreement. But for the record:

* I don't mind having Unicode alternatives, but there must be ASCII syntax too

* I think we must use ordinary dot for field selection.

* I think it's fine to insist on no spaces; we are already doing this for qualified names, as someone pointed out

* I think we should not introduce new syntax unless we are absolutely forced into it. Haskell's record update syntax isn't great, but we have it.

Conclusion ~~~~~~~~~~ I am driven to the conclusion that SORF is the way to go. - Every other proposal on the table requires SORF (either visibly or invisibly) - When you have SORF, you don't really need anything else

The blocking issues are described on

http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields

...

a) "Representation hiding" (look for that heading)

b) "Record update" (ditto), most especially for records whose fields have polymorphic types

I posted to the wiki a possible solution to (b):

http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields#Alte...

...

...

If we fix these we can move forward.

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users