Posting etiquette, was Re: Records in Haskell
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 simo...@microsoft.com 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/TypeDirectedNameResolution
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,
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 malcolm.wall...@me.comwrote:
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 simo...@microsoft.com 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/TypeDirectedNameResolution
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,
Re: Posting etiquette, was Re: Records in Haskell
Hi, On 01/19/2012 10:22 AM, Jos Pedro Magalhes wrote: 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. But then what is the point of including the text in the first place if it is understood it is only there to be hidden? Besides, personally, I don't want my e-mail client to attempt (and, short of it truly having an understanding of what is being said, inevitably fail) to understand which parts of an e-mail are of interest to me and which parts are not. No, I agree completely with Malcolm: not taking the time to quote ONLY what is of relevance to provide the immediately relevant context for a point one wishes to make is a failure of communication and, indeed, an abuse of other's time. Thanks, Malcolm, well said! /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Posting etiquette, was Re: Records in Haskell
On 19/01/2012, Malcolm Wallace malcolm.wall...@me.com wrote: 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. Regards, Malcolm Sorry. The reason that I have done so is that my primary mail client (GMail web) automatically folds quoted text (marked by at start of line). (I'm not sure whether my secondary client (mutt) can do so.) When I first saw this message, I thought I would be slammed for top-posts (I have been guilty a few times). Anyhow, I shall keep this in mind. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Posting etiquette, was Re: Records in Haskell
On January 19, 2012 05:14:30 Malcolm Wallace wrote: 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). +1 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
