<br><br>On Saturday, May 7, 2016, wren romano <<a href="mailto:wren@community.haskell.org">wren@community.haskell.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, May 6, 2016 at 3:58 PM, Cale Gibbard <<a href="javascript:;" onclick="_e(event, 'cvml', 'cgibbard@gmail.com')">cgibbard@gmail.com</a>> wrote:<br>
> I can't really be the only one here who thinks that this kind of<br>
> discussion of extensions to the syntax of Haskell is totally<br>
> inappropriate when we have a large number of already implemented<br>
> extensions to the language whose interactions with each other are<br>
> largely undocumented. The Haskell Report isn't the place to be talking<br>
> about new features, in my mind. If this project turns into<br>
> bike-shedding the concrete syntax of the language, it's hard to<br>
> imagine real progress being made on the actual problem, which is that<br>
> the Haskell Reports as they stand are not as relevant as they should<br>
> be with regard to the language in which we're writing programs today.<br>
<br>
<br>
+1.<br>
<br>
One of my big concerns here is that the proposal is vague, and<br>
therefore impossible to judge. As an example of what I mean, what<br>
counts as a "separator"? Is it a special case only commas? Why not<br>
also include the vertical pipe in data type definitions? We run into<br>
the same "difficult to one-line merge" issues when we write things<br>
like:<br>
<br>
    data SomeReallyLongNameSoIWantToNewlineWrap<br>
        = Foo ...<br>
        | Bar ...<br>
        ...<br>
<br>
Coq and other ML-like languages allow a vertical pipe between the "="<br>
and the first constructor name, so why shouldn't we? Or, what about<br>
when people do parser combinator stuff and use the (<|>) operator as a<br>
"separator", should we handle that too? If so, do we extend it to<br>
other operators people may want as a leading separator, like (+) in<br>
large arithmetic expressions? How should these be distinguished from<br>
typos where an argument is missing or a section was indented?<br>
<br>
<br>
These sorts of complexities are the reason the Haskell' committee has<br>
always focused on things which have already been implemented. The<br>
implementation provides (a) a concrete specification of what's being<br>
proposed, (b) an idea of how that proposal works in the wild, (c) a<br>
proof that it's easily implementable. Of course, in the process of<br>
getting included into the report the details may change; but it's a<br>
very solid starting point. I'm not adamantly opposed to proposals<br>
which aren't already implemented, but the proposal should measure up<br>
to the same standards— N.B., it may appear to be held to higher<br>
standards, since people often neglect to consider the role an<br>
implementation plays as a component of the proposal itself.<br>
<br>
As you say, four years is a decent chunk of time. Why not spend that<br>
time getting it implemented as an extension in GHC? The implementation<br>
process will work out a bunch of kinks in what exactly you mean by<br>
"separators" and how to handle leading vs trailing vs redundant<br>
separators. Having it available will also make it clearer how many<br>
people like and want this behavior. Both of these contribute to making<br>
the argument that we should in fact include it in the report.<br>
<br>
--<br>
Live well,<br>
~wren<br>
______________________________</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote><div><br></div><div>+1</div><div><br></div><div><span></span> </div><div><br></div><div> </div>