Moving ArgumentsDo forward
Akio Takano
tkn.akio at gmail.com
Mon Jul 4 07:50:55 UTC 2016
Hi Simon,
I'm sorry about the late reply.
On 2 June 2016 at 07:19, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> Akio
>
> Thanks for bringing back the ArgumentsDo question.
>
> My personal take on it is similar to Bardur:
>
>> AFAICT at best it's a *very* small improvement[1] and fractures
>> Haskell syntax even more around extensions -- tooling etc. will need
>> to understand even *more* syntax extensions[2].
>
> The benefit to me seems slight. The cost is also modest, but it is not zero (see below), even given a complete implementation. ANY feature carries a cost that is borne by every subsequent implementor, in perpetuity.
I understand your concern. I think this extension is worthwhile, but
of course this should be ultimately decided on by people who actually
maintain GHC.
>
> So I am a bit reluctant.
>
> These things are a judgement call, and we don't have a good process for making that decision. A few of us have been talking about putting forward a better process; it'll be a few weeks.
>
> Meanwhile, what to do about ArgumentDo? You say
>
> | I disagree that this is a small improvement, but I don't intend to
> | debate this here. As you said, nothing has really changed since it was
> | discussed before, and a lot of reasons for implementing this extension
> | have been already pointed out. I don't have anything to add.
>
> Is there a wiki page that describes the proposal, and lists the "lot of reasons" why it would be a good thing? And lists any disadvantages? I'm not just erecting obstacles: the trouble with email is that it is long and discursive, so it's really hard to find all the relevant messages, and even if you do each message only makes sense if you read the long sequence.
I made a wiki page: https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo
>
> One question I have is this. Presumably
> f do stmts
> will be represented as
> HsApp (HsVar f) (HsDo ...stmts...)
> And should print without parens -- they are signalled by HsPar. So what about
> (HsApp (HsVar f) (HsDo ...stmts1..)) (HsDo ..stmts2..)
> How does that pretty-print. I suppose it should be
> f do stmts1
> do stmts2
> That is, it must use layout. But at the moment the pretty printer doesn't do that.
It looks like the pretty printer always prints curly braces around do
statements (ppr_do_stmts in hsSyn/HsExpr.hs), so perhaps this is not
an issue?
- Akio
More information about the ghc-devs
mailing list