[Haskell-cafe] GHC Extension Proposal: ArgumentBlock

Tue Sep 8 01:08:11 UTC 2015

+1 people who like it can use it and people who don't like it don't have to
use it. Personally I wish it were the default because the superfluous $
confuses a lot of people coming from other languages like Ruby.

You can even write in the old style if you have the extension turned on. It
doesn't disable the old way of doing things. It just allows a new way. It's
entirely backwards compatible with working code when turned on, is it not?

On Monday, September 7, 2015, Andrew Gibiansky <andrew.gibiansky at gmail.com>
wrote:

> 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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>>> <javascript:_e(%7B%7D,'cvml','mail at joachim-breitner.de');> •
>>>> http://www.joachim-breitner.de/
>>>>   Jabber: nomeata at joachim-breitner.de
>>>> <javascript:_e(%7B%7D,'cvml','nomeata at joachim-breitner.de');>  •
>>>> GPG-Key: 0xF0FBF51F
>>>>   Debian Developer: nomeata at debian.org
>>>> <javascript:_e(%7B%7D,'cvml','nomeata at debian.org');>
>>>>
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> Haskell-Cafe at haskell.org
>>>> <javascript:_e(%7B%7D,'cvml','Haskell-Cafe at haskell.org');>
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>>
>>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> <javascript:_e(%7B%7D,'cvml','Haskell-Cafe at haskell.org');>
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>
>

-- 
-- Dan Burton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/170f62f0/attachment.html>