Limber separators

[wren romano]

On Fri, May 6, 2016 at 3:58 PM, Cale Gibbard <cgibbard at gmail.com> wrote:
> I can't really be the only one here who thinks that this kind of
> discussion of extensions to the syntax of Haskell is totally
> inappropriate when we have a large number of already implemented
> extensions to the language whose interactions with each other are
> largely undocumented. The Haskell Report isn't the place to be talking
> about new features, in my mind. If this project turns into
> bike-shedding the concrete syntax of the language, it's hard to
> imagine real progress being made on the actual problem, which is that
> the Haskell Reports as they stand are not as relevant as they should
> be with regard to the language in which we're writing programs today.


+1.

One of my big concerns here is that the proposal is vague, and
therefore impossible to judge. As an example of what I mean, what
counts as a "separator"? Is it a special case only commas? Why not
also include the vertical pipe in data type definitions? We run into
the same "difficult to one-line merge" issues when we write things
like:

    data SomeReallyLongNameSoIWantToNewlineWrap
        = Foo ...
        | Bar ...
        ...

Coq and other ML-like languages allow a vertical pipe between the "="
and the first constructor name, so why shouldn't we? Or, what about
when people do parser combinator stuff and use the (<|>) operator as a
"separator", should we handle that too? If so, do we extend it to
other operators people may want as a leading separator, like (+) in
large arithmetic expressions? How should these be distinguished from
typos where an argument is missing or a section was indented?


These sorts of complexities are the reason the Haskell' committee has
always focused on things which have already been implemented. The
implementation provides (a) a concrete specification of what's being
proposed, (b) an idea of how that proposal works in the wild, (c) a
proof that it's easily implementable. Of course, in the process of
getting included into the report the details may change; but it's a
very solid starting point. I'm not adamantly opposed to proposals
which aren't already implemented, but the proposal should measure up
to the same standards— N.B., it may appear to be held to higher
standards, since people often neglect to consider the role an
implementation plays as a component of the proposal itself.

As you say, four years is a decent chunk of time. Why not spend that
time getting it implemented as an extension in GHC? The implementation
process will work out a bunch of kinks in what exactly you mean by
"separators" and how to handle leading vs trailing vs redundant
separators. Having it available will also make it clearer how many
people like and want this behavior. Both of these contribute to making
the argument that we should in fact include it in the report.

-- 
Live well,
~wren