On Saturday, May 7, 2016, wren romano <w...@community.haskell.org> wrote:
> On Fri, May 6, 2016 at 3:58 PM, Cale Gibbard <cgibb...@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
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
