Limber separators

[Carter Schonwald]

On Saturday, May 7, 2016, wren romano <wren at community.haskell.org> wrote:

> On Fri, May 6, 2016 at 3:58 PM, Cale Gibbard <cgibbard at gmail.com
> <javascript:;>> 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
> ______________________________


>
+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20160508/66effd39/attachment.html>