Re: Chairship / responsibility

2016-05-09 Thread Henk-Jan van Tuyl 

On Sat, 30 Apr 2016 10:03:55 +0200, Herbert Valerio Riedel
 wrote:


Hello *,

:

| In consultation with the current members of the Haskell Prime
| committee (and Simon PJ), I have volunteered as chair to "reboot" the
| process and get things rolling again.

:

I think it's great that you want to do this!

Regards,
Henk-Jan van Tuyl


--
Folding@home
What if you could share your unused computer power to help find a cure? In
just 5 minutes you can join the world's biggest networked computer and get
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Infrastructure & Communication

2016-05-09 Thread Henk-Jan van Tuyl 

On Sun, 01 May 2016 00:22:44 +0200, Austin Seipp 
wrote:
:

  - It has strong access control mechanisms. This means the Prime
committee can do things like have private discussion, outside of usual
e.g. email. I know people are intimately leery of this, but I think in
practice people form private discussion channels anyway, and having
private avenues for discussing larger public things in an easy way
(chat rooms, tickets etc) is desirable. The lack of a sanctioned
private channel IMO will only cause Prime members to discuss in
private *anyway*, but in disjoint groups probably. I don't think we
should use it all the time, but I can imagine we might want this - I
didn't see it brought up.

:

Previous committees used a mailing list for this, the most recent one is:
haskell-2011-commit...@haskell.org

I am not saying we should repeat this, just mentioning the option.

Regards,
Henk-Jan van Tuyl


--
Folding@home
What if you could share your unused computer power to help find a cure? In
just 5 minutes you can join the world's biggest networked computer and get
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

RE: The GADT debate

2016-05-09 Thread Augustsson, Lennart 
Do you really need that many type signatures?  I remember trying to work out 
what extra information is needed when type checking case with dependent types.  
If memory serves, you can get by with just specifying the single (type) 
function that is instantiated in each arm and in the conclusion.  Maybe 
something similar is possible here.

   

-Original Message-
From: Haskell-prime [mailto:haskell-prime-boun...@haskell.org] On Behalf Of 
Richard Eisenberg
Sent: 08 May 2016 16:25
To: Gershom B
Cc: haskell-prime@haskell.org List
Subject: Re: The GADT debate


On May 7, 2016, at 11:05 PM, Gershom B  wrote:
> 
> an attempt (orthogonal to the prime committee at first) to specify an 
> algorithm for inference that is easier to describe and implement than 
> OutsideIn, and which is strictly less powerful. (And indeed whose 
> specification can be given in a page or two of the report).

Stephanie Weirich and I indeed considered doing such a thing, which 
conversation was inspired by my joining the Haskell Prime committee. We 
concluded that this would indeed be a research question that is, as yet, 
unanswered in the literature. The best we could come up with based on current 
knowledge would be to require type signatures on:

1. The scrutinee
2. Every case branch
3. The case as a whole

With all of these type signatures in place, GADT type inference is indeed 
straightforward. As a strawman, I would be open to standardizing GADTs with 
these requirements in place and the caveat that implementations are welcome to 
require fewer signatures. Even better would be to do this research and come up 
with a good answer. I may very well be open to doing such a research project, 
but not for at least a year. (My research agenda for the next year seems fairly 
solid at this point.) If someone else wants to spearhead and wants advice / a 
sounding board / a less active co-author, I may be willing to join.

Richard
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

This email and any attachments are confidential and may also be privileged. If 
you are not the intended recipient, please delete all copies and notify the 
sender immediately. You may wish to refer to the incorporation details of 
Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at 
http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market 
commentary has been prepared by sales and/or trading desk of Standard Chartered 
Bank or its affiliate. It is not and does not constitute research material, 
independent research, recommendation or financial advice. Any market commentary 
is for information purpose only and shall not be relied for any other purpose, 
and is subject to the relevant disclaimers available at 
http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx

Insofar as this e-mail contains the term sheet for a proposed transaction, by 
responding affirmatively to this e-mail, you agree that you have understood the 
terms and conditions in the attached term sheet and evaluated the merits and 
risks of the transaction. We may at times also request you to sign on the term 
sheet to acknowledge in respect of the same.

Please visit 
http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx
 for important information with respect to derivative products.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

RE: Are there GHC extensions we'd like to incorporate wholesale?

2016-05-09 Thread Simon Peyton Jones 
Just to be clear, MonoLocalBinds, as implemented, does not apply to local 
bindings that could equally well have been written at top level; that is, they 
do not mention any locally-bound variables (except other local bindings that 
could themselves be floated).

So you are at liberty to use where for stylistic reasons.

You may still dislike the cure, but the disease is pretty bad.  Do suggest 
alternative cures!

This is not to argue for or against MonoLocalBinds for Haskell Prime.

Simon

|  -Original Message-
|  From: Haskell-prime [mailto:haskell-prime-boun...@haskell.org] On
|  Behalf Of wren romano
|  Sent: 08 May 2016 02:40
|  To: haskell-prime@haskell.org List 
|  Subject: Re: Are there GHC extensions we'd like to incorporate
|  wholesale?
|  
|  On Wed, May 4, 2016 at 2:51 AM, Dominique Devriese
|   wrote:
|  > As an outsider, I would like to suggest thinking about
|  MonoLocalBinds.
|  > GHC has a rather convincing story (at least to me) that "(local) let
|  > should not be generalised" (since it becomes problematic in
|  > combination with several other language extensions) and the journal
|  > version of the OutsideIn(X) paper has empirical data that indicates
|  it
|  > is not a big problem to remove.  If there is a concern about
|  backwards
|  > compatibility, perhaps the committee could deprecate local let
|  > generalisation in Haskell2020 and remove it in a subsequent iteration
|  of the report?
|  
|  
|  FWIW, I'm against MonoLocalBinds. I understand the rational given in
|  the paper, but I disagree with it. In my experience the medicine is
|  worse than the disease.
|  
|  It used to be that where-clauses where a nice clean way of organizing
|  code, especially for things like the worker/wrapper transform; but with
|  MonoLocalBinds all the benefits of where-clauses are eliminated.
|  For every local binding I'm forced to provide a type signature —because
|  part of the whole *point* of factoring things out is that you're going
|  to use them repeatedly, which for GADTs virtually guarantees the uses
|  will be at different index types and therefore will require universal
|  quantification— and these requisite type signatures almost entirely
|  duplicate information provided by the signature for the primary/top-
|  level binding. Indeed, in almost every situation I end up needing to
|  manually provide type signatures which are identical to what let-
|  generalization would have inferred. This repetition is not merely
|  annoying, it actively harms legibility and maintainability of code.
|  
|  --
|  Live well,
|  ~wren
|  ___
|  Haskell-prime mailing list
|  Haskell-prime@haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
|  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fhaskell-
|  prime=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cd15df870d2b4441
|  c57c808d376e19b35%7c72f988bf86f141af91ab2d7cd011db47%7c1=U2WAdUt4
|  qXclT7F7G93J1zVylYv3CvhqNuNHeem%2fvEg%3d
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime