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
(Continue reading)

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
(Continue reading)

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
(Continue reading)

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 )?

Best regards


|--------- Dr. Christian Siefkes --------- christian@... ---------
| Homepage:   |   Blog:
| Wie Produktion zur Nebensache wurde:
| Why Production No Longer Worries Us:
|------------------------------------------- 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                          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.
(Continue reading)

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>> 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
(Continue reading)

Re: Evaluation order control between two expressions

Hello Takenobu,

Great question, this is actually a pretty interesting issue! It isn't
out of scope at all.

The first thing to think about is the following thought experiment:

Without the presence of side-effects, how can you tell the difference
between a `seq` that conforms to the Haskell report and one that
evaluates it's first argument before its second?

If your answer involves `unsafePerformIO` then you're cheating ;)

Even if your first argument to `seq` is an IO action it won't get
executed because `seq` only evaluates to WHNF. It might be possible to
construct a program that allows you to observe the difference, but in
the general case I don't see how you could. I'd be very interested to
be shown otherwise though!

Now in a parallel program things change. When we use `pseq` it's
because we don't want two threads to collide when trying to evaluate
the same expression. Let's look at an example:

x `par` y `seq` x + y

As you noted, the semantics of `seq` doesn't actually guarantee that
`y` will be evaluated before `x + y`. But this only matters because
we've used `par` and introduced threads (via an effect!) and therefore
the possibility of collision. We can avoid this by using `pseq`
(Continue reading)