Scope of committee (can we do *new* things?)

[Richard Eisenberg]

On May 8, 2016, at 6:27 AM, Alexander Berntsen <alexander at plaimi.net> wrote:
> 
> I realise now that the report is not the place to fix problems with
> Haskell, but to standardise solutions that a high enough percentage of
> packages already rely on. I misjudged the ambition level of the
> report. Thus I withdraw this proposal to not waste the committees time
> any further.

The above snippet has been taken from the "Limber separators" thread. I don't wish to debate limber separators at the moment, but I think Alexander raises a good question here: 

Should we endeavor to take on any as-yet-unimplemented behavior that might make Haskell better?

My own opinion is a resounding "yes!"

If we say "no", we're left with a terrible chicken-and-egg problem. I have seen some proposed extensions to GHC be thrown out because they would fragment the language unnecessarily. Chief in my head is that proposal to allow `case`, `if`, `do`, etc., in a function application without parentheses or a $ operator. That is, to permit `runST do blah; blah`. (See https://ghc.haskell.org/trac/ghc/ticket/10843) A common rebuttal against this proposal was that implementing the extension would involve a lot of huffing and puffing over a few characters, and that now all Haskell readers may have to be aware of this new extension, even if an individual doesn't write with it. However, the Haskell Prime committee is a great place to debate such a change. If we move quickly, we can even implement it, get it into GHC (or some other Haskell compiler, I suppose), and get feedback before we set the standard in stone.

I do absolutely think we should be cautious about addressing unimplemented behavior. I would be strongly against a new type-system extension that hasn't been field-tested. However, I do think pondering lexical/parsical changes (such as limber separators) should be considered in scope.

Richard