[Haskell-cafe] GHC Extension Proposal: ArgumentBlock

[Andrew Gibiansky]

We would need ghc-exactprint to provide a good source to source
transformation for error messages. Otherwise using this quasi-extension
would be quite problematic in real-world work.

I actually really like this idea -- it would give us a way to experiment
with new syntax easily, including things such as changing `type`, `data`,
`newtype`, and any other syntactic woes we might have about the Haskell
language.

-- Andrew

On Mon, Sep 7, 2015 at 11:25 AM, Oliver Charles <ollie at ocharles.org.uk>
wrote:

> I don't think you need ghc-exactprint for that - you can just write a GHC
> preprocessor, hopefully being able to reuse the current grammar
> specification you already have. See the -prgmF option (I think it's called
> that, best check the GHC manual). You don't really care about the source
> code formatting, because you're going to pass it straight off to the
> compiler anyway. Though I guess maybe exactprint could help so error
> messages still map cleanly.
>
> On Mon, Sep 7, 2015 at 6:57 PM Andrew Gibiansky <
> andrew.gibiansky at gmail.com> wrote:
>
>> So, it looks like this extension is quite controversial. To summarize the
>> main points raised in this discussion:
>>
>> Pro: (+9)
>>     - It's easier to read than the alternative.
>>     - This extension removes syntactic noise.
>>     - This makes basic do-syntax more approachable to newbies; it is a
>> commonly asked question as to why the $ is necessary.
>>     - This simplifies the resulting AST, potentially making it simpler
>> for editors and other tools to do refactoring.
>>     - It's something that belongs in the main language, and if its
>> something we'd consider for a mythical Haskell', it has to start as an
>> extension.
>>     - It gets rid of some cases where using $ doesn't work because $
>> interacts with other infix operators being used in the same expression.
>>     - This would make do blocks consistent with record creation, where
>> parentheses are skipped, allowing things such as "return R { x = y}"
>>     - This does not change the meaning of any old programs, only allows
>> new ones that were previously forbidden.
>>     - This gets rid of the need for a specially-typed $ allowing "runSt $
>> do ..."
>>
>> Con: (-9)
>>     - It's harder to read than the alternative.
>>     - Creating a language extension to get rid of a single character is
>> overkill and unnecessary.
>>     - You can already get rid of the $ by just adding parentheses.
>>     - More and more syntactic "improvements" just fragment the language.
>>     - Although this is consistent with record syntax, record syntax
>> without parents was a mistake originally.
>>
>> Questions:
>>     - Why doesn't this apply to case, let, if, etc?
>>     - Should this apply to case, let, if, etc?
>>
>> I would say people on /r/haskell and haskell-cafe seem fairly evenly
>> split, perhaps somewhat favoring *not* including this extension.
>>
>> 1. How representative are the opinions expressed through these media of
>> the general Haskell community? (If one exists...)
>> 2. What, historically, has been the GHC policy on including
>> questionable/controversial extensions?
>> 3. We do have another option: with the advent of ghc-exactprint, we could
>> probably write a preprocessor that emulates this extension, parsing as if
>> ArgumentDo is enabled and then inserting a $ where necessary. This would
>> allow us to test out this extension without modifying GHC and thus being
>> stuck with the extension in mainline GHC indefinitely (since, as I
>> understand it, there's not really a process for *removing* extensions from
>> GHC).
>>
>>
>> On Mon, Sep 7, 2015 at 5:10 AM, Joachim Breitner <
>> mail at joachim-breitner.de> wrote:
>>
>>> Hi,
>>>
>>> Am Sonntag, den 06.09.2015, 11:28 -0700 schrieb Andrew Gibiansky:
>>> > 3. It does make some cases cleaner. Consider the following code: [1,
>>> > 2, 3] ++ concat (do { .... }). This can be written with parentheses,
>>> > bit it cannot be written with $, because [1, 2, 3] ++ concat $ do {
>>> > .... } would parse as ([1, 2, 3] ++ concat) $ do { ... }. This is
>>> > sometimes annoying behaviour. (I used the list monad here just for
>>> > demo purposes. I find it is more common with applicative operators.)
>>>
>>> good point! This has bitten me before.
>>>
>>> I believe that the language would be better with the proposed syntax
>>> change being the default. So the way forward is to indeed add this
>>> extension, see how people use it, and if Haskell' ever goes somewhere,
>>> it might include this as the default – all alike to DoAndIfThenElse.
>>>
>>> Also note that this does not change the meaning of any existing
>>> program, AFAIK. So it is not that you might be reading existing code
>>> wrongly if you are not aware that this extension is being used; you
>>> will just find code that looks like invalid syntax to you – until you
>>> check the list of extensions (or just deduce that ArgumentBlock is used
>>> here).
>>>
>>> Therefore, +1 from me.
>>>
>>> Greetings,
>>> Joachim
>>>
>>> --
>>> Joachim “nomeata” Breitner
>>>   mail at joachim-breitner.de • http://www.joachim-breitner.de/
>>>   Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0xF0FBF51F
>>>   Debian Developer: nomeata at debian.org
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/9aa9f13b/attachment.html>