Iavor Diatchki | 31 May 19:50 2016

Infrastructure status?


what is the status of the discussion about how we should collaborate?   I am not picky and would be happy to use whatever tools others prefer.  If it was left to me, I'd use: 1) a git repo on github, which contains the current version of the report, and various proposals, and 2) this e-mail list for discussion.

As I said before, I think it might be quite nice as a first step to standardize something simple, and hopefully not too controversial, so that we can all familiarize ourselves with the basic process.

Haskell-prime mailing list
Anton Felix Lorenzen | 19 May 11:20 2016

Re: New Proposal: EasyMacros

I am glad you like the idea. I fully understand
that it should be an extension first, I simply followed the 

I am think I am not able to make a prime wiki page
(at least I wasn't able to find a button for this).

Should I create a ghc wiki page?
Email the Haskell-cafe list?

This is my first proposal and I m a bit lost here.

Anton Felix Lorenzen | 18 May 21:10 2016

New Proposal: EasyMacros

Hello list,

I want to propose a new way of writing template-haskell macros.
It is based on the idea, that syntax like this:
do {
    x <- getLine;
    putStrLn x;
should be parsed into:
$( do
    [ [| x <- getLine |]
    , [| putStrLn x   |]
    ] )
Then a function (do :: NonEmpty ExpQ -> ExpQ) will be called
and executed.

This would allow for a couple of useful macros:
   - do
   - case
   - fold -- fold the ExpQs into one, see below for details
   - eval -- evaluate ExpQs at compile-time
   - (maybe even) hamlet -- evaluate hamlet QQ
   - CPP replacements?

Nothing will be added which isn't possible today.
Nonetheless it will allow for a much cleaner syntax
and by this make things usable which weren't usable before.

Also it might be easier to implement new features.
For example ApplicativeDo and RecursiveDo
could have been implemented by a hackage package.
MultiWayIf could be a function, too.

   map (replicate 3)

   "Hello World! \n"
   "How are you? \n"


===== Example Macros =====

see in context: https://github.com/anfelor/EasyMacros

conc = fold [| (++) |]
apply = fold [|flip ($)|]

fold :: ExpQ -- (a -> b -> c)
    -> NonEmpty (Q Exp) -> Q Exp
fold _ (a :| []) = a
fold fn (a :| b : xs) = fold fn (([| fn $a $b |]) :| xs)

do_ :: NonEmpty (Q Stmt) -> Q Exp
do_ (x :| []) = x >>= \case
      BindS _ _ -> fail "The last statement in a 'do' block must be an 
      NoBindS e -> return e
do_ (x :| xs) = x >>= \case
      BindS pat exp -> [| $(return exp) >>= \ $(return pat) -> $(do_ 
(fromList xs)) |]
      NoBindS   exp -> [| $(return exp) >> $(do_ (fromList xs)) |]
wren romano | 8 May 04:30 2016

The GADT debate

Hi all,

There's been some discussion about whether to consider including GADTs
in the new report, but it's been mixed up with other stuff in the
thread on incorporating extensions wholesale, which has unfortunately
preempted/preceded the discussion about how to go about having such

My position on the debate is that we should avoid having the debate,
just yet. (Which I intended but failed to get across in the email
which unintentionally started this all off.) I think we have many much
lower-hanging fruit and it'd be a better use of our time to try and
get those squared away first. Doing so will help us figure out and
debug the process for having such debates, which should help the GADT
debate itself actually be fruitful. As well as making progress on
other fronts, so we don't get mired down first thing.

Whenever the debate occurs, here's a summary of the relevant emails so
that they are not lost, buried in the emails of time:

* Andres Löh puts forth criteria on how to judge whether extensions
should be included. Mentions GADTs as an example of something that, if
we decide they're a good idea in principle (criterion #1), then we
should work towards things which will help them be easier to
feasibly/sensibly specify (criterion #2)


* wren agrees with the criteria, loves GADTs, thinks they do not fully
satisfy criterion #2


* Simon Peyton Jones says type inference for GADTs has, in fact,
stabilized. Albeit, not entirely satisfactory because it's "a bit


* Henrik Nilsson thinks GADTs are one of the most important extensions
to Haskell (fwiw, wren agrees). Also worries about being able to
specify type inference declaratively.


* Dominique Devriese suggests including MonoLocalBinds, finds "let
should not be generalized" convincing


* wren finds "let should not be generalized" unconvincing



Live well,
Haskell-prime mailing list
Haskell-prime <at> haskell.org
M Farkas-Dyck | 6 May 18:32 2016

Re: Infrastructure & Communication

I think we ought to make a choice quite soon. Proposals are already
being made on this list, but i hesitate to make comment lest it be
forgotten when we move to our new medium.

My opinion on our choice of medium is known, i believe. Who or what
makes the final call? hvr? committee member votes?
Alexander Berntsen | 6 May 15:09 2016

Limber separators

Haskell uses separators for values in a number of syntactic
constructs. It is my understanding of the 2010 report that the
language does however not generally support leading separators, nor
trailing separators, nor both (two exceptions are discussed at the end
of this email). Consequently diffs are bloated, resulting in mental
overhead when viewing and reviewing patches, as well as potential
three-way merge conflicts or worse. A quick example:

[ Foo
, Bar
, Fu
, Baz

It is impossible to remove values Foo or Baz with a one line diff. It
is additionally impossible to reasonably add a new value to the top or
bottom of the list.

I want the Haskell' committee to discuss allowing one or more of the

* Leading separators
* Trailing separators
* No separators

The former two, or a combination, is arguably the least invasive
modification, whilst the latter is more sensible as a language
extension for now as it would break code. The latter is furthermore
difficult as the rules are potentially more involved, yielding more
gotchas. My immediate suggestion for the no separators route would be
to use newlines.

The discussion should apply to as many contexts as deemed sensible. It
is arguably insensible to introduce leading or trailing separators
where we would end up with ambiguity, as would be the case with tuple
declarations due to tuple sections. Examples of where it would be
sensible are abundant, and include -- but aren't limited to -- data
types, lists, record fields, pattern guards, and language pragmas.

If leading separators, or trailing separators, or both, are accepted
as the way to go forward, perhaps permit extra separators in general.
I.e. [,,,Foo,,,Bar,,,Fu,,,Baz,,,] is a list with four terms, Foo, Bar,
Fu, and Baz.

Please note that Haskell 2010 already permits trailing commas in
import and export lists, like so:

impspec → ( import1 , … , importn [ , ] ) (n ≥ 0)
exports → ( export1 , … , exportn [ , ] ) (n ≥ 0)

Meaning the following is legal:

import Foo (

And the following:

module Foo (

Bizarrely, the following is *not* legal:

import Foo (
  Bar (

I.e. impspecs are permitted trailing commas, imports aren't.

alexander <at> plaimi.net
Christian Siefkes | 4 May 11:35 2016

Starting point for new standard?

Hi all,

out of curiosity, what'll be the starting point for the next Haskell report?
I suppose Haskell 2010 plus the additional "No Datatype Contexts" change
accepted by the old Haskell Language committee in early 2011 (see
https://wiki.haskell.org/Haskell_2010#Additional_change )?

Best regards


|--------- Dr. Christian Siefkes --------- christian@... ---------
| Homepage:   http://www.siefkes.net/   |   Blog:   http://www.keimform.de/
| Wie Produktion zur Nebensache wurde: www.keimform.de/2013/freie-quellen-1/
| Why Production No Longer Worries Us: www.keimform.de/2013/free-sources-1/
|------------------------------------------- OpenPGP Key ID: 0x980FA6ED --
2 + 2 = 5 for suitably large values of 2.

Haskell-prime mailing list
John Wiegley | 3 May 00:57 2016

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

I wonder if there are GHC extensions we'd like to promote as features in the
next report, as a starting point for discussing new additions.

There are a few GHC features that have become part of the regular Haskell
landscape, such that it's hard to imagine a modern Haskell without them. For
example, MultiParamTypeClasses, OverloadedStrings, GADTs, TypeFamilies, etc.

How much "work" is typically involved in promoting a feature to be in the
Report, and how do we determine when it's a bad idea?


John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
Herbert Valerio Riedel | 30 Apr 10:03 2016

Re: Chairship / responsibility

Hello *,

On 2016-04-29 at 15:17:43 +0200, Richard Eisenberg wrote:
> Is there a chair of this committee? Herbert has been acting as such
> (thank you!) but doesn't list himself as the chair in the initial
> announcement.
> I am **in no way** trying to change any status quo and
> am **not** interested in being chair at the moment, but I just wanted
> to clarify.

Fwiw, I mentioned in the preceding CfN

| 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.

But you're right I failed to repeat this in the actual announcement.

However, I don't want to impose myself on the committee as chair. So if
anyone else feels motivated enough to pick up the role as chair with the
agreement of the committee I'll happily hand over the chair position!

Moreover, this doesn't need to be a static configuration: We could also
rotate the chair position (and other duties) over the lifetime of the
Haskell 2020 committee. There just needs to be one designated chair at
any time to keep things moving.

> The specific reason I ask is that Takenobu Tani recently asked about
> `pseq`. I have no intelligent response to offer, but would want to
> make sure that someone does offer a response. If there is a chair,
> that person is de facto responsible that we, as a committee,
> communicate well, both internally and externally.

You're definitely right. And IMO the chair only needs to step in if
nobody else feels compelled to respond within a reasonable time, e.g. a
few days -- after all, we all have other duties besides the prime
committee :-)

-- hvr
Haskell-prime mailing list
wren romano | 30 Apr 04:51 2016

Re: Chairship / responsibility

> Hi Prime,
> Is there a chair of this committee? Herbert has been acting as such (thank you!) but doesn't list himself as
the chair in the initial announcement. I am **in no way** trying to change any status quo and am **not**
interested in being chair at the moment, but I just wanted to clarify.
> The specific reason I ask is that Takenobu Tani recently asked about `pseq`. I have no intelligent
response to offer, but would want to make sure that someone does offer a response. If there is a chair, that
person is de facto responsible that we, as a committee, communicate well, both internally and externally.

I don't know that we have one (officially), but I agree that
getting/agreeing-on one should be done soon.


Live well,
wren romano | 30 Apr 04:49 2016

Re: Infrastructure & Communication

On Fri, Apr 29, 2016 at 9:17 AM, Mario Blažević <blamario <at> ciktel.net> wrote:
>     There are two or three distinct components we need to keep track of: the
> draft standard, discussions, and potentially RFCs.
>     Discussions can be hosted on this mailing list, on Trac, or as Git
> issues. Each of them would serve fine, but we should choose exactly one and
> stick to it. The mailing list looks pretty good in isolation, but the best
> choice depends on whether we want to have RFCs or not.
>     If we support Requests for Comments, we'll need to also support their
> public submissions and Git pull requests or something to the same effect. In
> that case, at least the inevitable comments on RFCs would best be placed
> close to the RFCs themselves - if the RFCs end up on GitHub the discussions
> of them should be kept as GitHub issues.

I agree with all of this, and think this distinction should be kept in
mind in terms of keeping things organized to whatever tools we choose.

For general discussions I think this mailing list is best. I'm cool
for keeping irc as a side channel for hashing things out more
interactively, but it's all to easy to miss things there so I think
it's best kept as a side channel not a main one.

I like (something like) GitHub issues for tracking the exact content
of proposed changes and their (direct) commentary. As far as the
particular tool I'm mostly agnostic, but lean slightly towards github
over trac. I've never used phabricator so can't say there (though I'm
slightly against, as it'd be another tool to learn.)

As far as wiki stuff goes, to be honest I'm kinda against it. I see
how it might could be helpful as a sort of staging ground prior to
actual RFCs, or as an edited synopsis of email discussion; but in my
experience the wiki proposals for Haskell changes tend to get very
crufty and hard to follow after a few changes have been made. I think
I'd rather see specific versioning on proposals, so it can be clear
when/which parts of the proposal are retracted, amended, etc. This may
very well be a reason to prefer github, since such development can
happen in branches where we can see the iteration of changes prior to
merging a specific one into the master branch.

/me goes off to read about how Fsharp, Rust, and Go do things


Live well,
Haskell-prime mailing list
Haskell-prime <at> haskell.org