Guidelines for respectful communication

[Simon Peyton Jones via Glasgow-haskell-users]

Friends
As many of you will know, I have been concerned for several years about the 
standards of discourse in the Haskell community.  I think things have improved 
since the period that drove me to write my Respect 
email, 
but it's far from secure.
We discussed this at a meeting of the GHC Steering 
Committee at ICFP in September, 
and many of us have had related discussions since.  Arising out of that 
conversation, the GHC Steering Committee has decided to adopt these
  Guidelines for respectful 
communication

We are not trying to impose these guidelines on members of the Haskell 
community generally. Rather, we are adopting them for ourselves, as a signal 
that we seek high standards of discourse in the Haskell community, and are 
willing to publicly hold ourselves to that standard, in the hope that others 
may choose to follow suit.
We are calling them "guidelines for respectful communication" rather than a 
"code of conduct", because we want to encourage good communication, rather than 
focus on bad behaviour.  Richard Stallman's recent 
post about the new GNU Kind Communication 
Guidelines expresses the 
same idea.
Meanwhile, the Stack community is taking a similar 
approach.
Our guidelines are not set in stone; you can comment 
here.
   Perhaps they can evolve so that other Haskell committees (or even 
individuals) feel able to adopt them.
The Haskell community is such a rich collection of intelligent, passionate, and 
committed people. Thank you -- I love you all!
Simon



<>___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Equality constraints (~): type-theory behind them

[Anthony Clayden]

The (~) constraint syntax is enabled by either `GADTs` or `TypeFamilies`
language extension.

GADTs/Assoc Data Types/Assoc Type Synonyms/Type Families arrived in a
series of papers 2005 to 2008, and IIRC the development wasn't finished in
full in GHC until after that. (Superclass constraints took up to about
2010.)

Suppose I wanted just the (~) parts of those implementations. Which would
be the best place to look? (The Users Guide doesn't give a reference.) ICFP
2008 'Type Checking with Open Type Functions' shows uses of (~) in
user-written code, but doesn't explain it or motivate it as a separate
feature.

My specific question is: long before (~), it was possible to write a
TypeCast class, with bidirectional FunDeps to improve each type parameter
from the other. But for the compiler to see the type improvement at term
level, typically you also need a typeCast method and to explicitly wrap a
term in it. If you just wrote a term of type `a` in a place where `b` was
wanted, the compiler would either fail to see your `TypeCast a b`, or unify
the two too eagerly, then infer an overall type that wasn't general enough.

(For that reason, the instance for TypeCast goes through some
devious/indirect other classes/instances or exploits separate compilation,
to hide what's going on from the compiler's enthusiasm.)

But (~) does some sort of magic: it's a kinda typeclass but without a
method. How does it mesh with type improvement in the goldilocks zone:
neither too eager nor too lazy?


AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users