Re: The GADT debate
On Saturday, May 7, 2016, Gershom B wrote: > On May 7, 2016 at 10:30:05 PM, wren romano (w...@community.haskell.org > ) wrote: > > Hi all, > > > > There's been some discussion about whether to consider including GADTs > > in the new report, but it's been mixed up with other stuff in the > > thread on incorporating extensions wholesale, which has unfortunately > > preempted/preceded the discussion about how to go about having such > > discussions(!). > > > > My position on the debate is that we should avoid having the debate, > > just yet. (Which I intended but failed to get across in the email > > which unintentionally started this all off.) I think we have many much > > lower-hanging fruit and it'd be a better use of our time to try and > > get those squared away first. Doing so will help us figure out and > > debug the process for having such debates, which should help the GADT > > debate itself actually be fruitful. As well as making progress on > > other fronts, so we don't get mired down first thing. > > Thanks for this summary Wren. Let me add something I would be interested > in seeing happen in the “meantime” — an attempt (orthogonal to the prime > committee at first) to specify an algorithm for inference that is easier to > describe and implement than OutsideIn, and which is strictly less powerful. > (And indeed whose specification can be given in a page or two of the > report). A compliant compiler could then be required to have inference “at > least” that good, but also be allowed to go “above and beyond”. Thus fully > portable H2020 code might require more specified signatures than we need in > GHC proper, but all such code would also typecheck in GHC. It seems to me > that the creation of such an algorithm might be an interesting bit of > research in itself. > > —Gershom I agree, there's definitely value in some research / engineering work that articulates a clear simple checker and a simple and slightly conservative inference alg , and that could pave a nice path towards gadts inclusion or at least a concrete starting point. Thanks for articulating this, I've been thinking much the same thing. Of course the proof is in the pudding for how it works out :) Peripherally, this also brings up the notion of type equality, and I'm a bit fuzzy about how big a chasm there is between what that means in Haskell 2010 vs more bleeding edge styles, or am I pointing at a shadows? > ___ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Limber separators
On Saturday, May 7, 2016, wren romano wrote: > On Fri, May 6, 2016 at 3:58 PM, Cale Gibbard > 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
Re: The GADT debate
On May 7, 2016 at 10:30:05 PM, wren romano (w...@community.haskell.org) wrote: > Hi all, > > There's been some discussion about whether to consider including GADTs > in the new report, but it's been mixed up with other stuff in the > thread on incorporating extensions wholesale, which has unfortunately > preempted/preceded the discussion about how to go about having such > discussions(!). > > My position on the debate is that we should avoid having the debate, > just yet. (Which I intended but failed to get across in the email > which unintentionally started this all off.) I think we have many much > lower-hanging fruit and it'd be a better use of our time to try and > get those squared away first. Doing so will help us figure out and > debug the process for having such debates, which should help the GADT > debate itself actually be fruitful. As well as making progress on > other fronts, so we don't get mired down first thing. Thanks for this summary Wren. Let me add something I would be interested in seeing happen in the “meantime” — an attempt (orthogonal to the prime committee at first) to specify an algorithm for inference that is easier to describe and implement than OutsideIn, and which is strictly less powerful. (And indeed whose specification can be given in a page or two of the report). A compliant compiler could then be required to have inference “at least” that good, but also be allowed to go “above and beyond”. Thus fully portable H2020 code might require more specified signatures than we need in GHC proper, but all such code would also typecheck in GHC. It seems to me that the creation of such an algorithm might be an interesting bit of research in itself. —Gershom ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Limber separators
On Fri, May 6, 2016 at 3:58 PM, Cale Gibbard 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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
The GADT debate
Hi all, There's been some discussion about whether to consider including GADTs in the new report, but it's been mixed up with other stuff in the thread on incorporating extensions wholesale, which has unfortunately preempted/preceded the discussion about how to go about having such discussions(!). My position on the debate is that we should avoid having the debate, just yet. (Which I intended but failed to get across in the email which unintentionally started this all off.) I think we have many much lower-hanging fruit and it'd be a better use of our time to try and get those squared away first. Doing so will help us figure out and debug the process for having such debates, which should help the GADT debate itself actually be fruitful. As well as making progress on other fronts, so we don't get mired down first thing. Whenever the debate occurs, here's a summary of the relevant emails so that they are not lost, buried in the emails of time: * Andres Löh puts forth criteria on how to judge whether extensions should be included. Mentions GADTs as an example of something that, if we decide they're a good idea in principle (criterion #1), then we should work towards things which will help them be easier to feasibly/sensibly specify (criterion #2) https://mail.haskell.org/pipermail/haskell-prime/2016-May/004104.html * wren agrees with the criteria, loves GADTs, thinks they do not fully satisfy criterion #2 https://mail.haskell.org/pipermail/haskell-prime/2016-May/004115.html * Simon Peyton Jones says type inference for GADTs has, in fact, stabilized. Albeit, not entirely satisfactory because it's "a bit operational" https://mail.haskell.org/pipermail/haskell-prime/2016-May/004119.html * Henrik Nilsson thinks GADTs are one of the most important extensions to Haskell (fwiw, wren agrees). Also worries about being able to specify type inference declaratively. https://mail.haskell.org/pipermail/haskell-prime/2016-May/004120.html * Dominique Devriese suggests including MonoLocalBinds, finds "let should not be generalized" convincing https://mail.haskell.org/pipermail/haskell-prime/2016-May/004117.html * wren finds "let should not be generalized" unconvincing https://mail.haskell.org/pipermail/haskell-prime/2016-May/004145.html -- Live well, ~wren ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Are there GHC extensions we'd like to incorporate wholesale?
On Wed, May 4, 2016 at 3:23 AM, Herbert Valerio Riedel wrote: > On 2016-05-04 at 06:48:38 +0200, wren romano wrote: >> Speaking of which, are things like the AMP and FTP under our purview >> or are they under the CLC? > > I tried to clarify in the call-for-nomination and the formation > announcement that the library part of the Haskell Report shall be > formally under the CL(i)C's purview I get that. My question was more because of how various things in the Prelude are hard-coded into the rest of the report— in particular, the core type classes feel like they span the boundary: the Monad class is needed for the IO type for `main`, the fromInteger method of Num and fromRational method of Fractional are needed for handling of numeric literals, etc. -- Live well, ~wren ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Are there GHC extensions we'd like to incorporate wholesale?
On Wed, May 4, 2016 at 2:51 AM, Dominique Devriese wrote: > As an outsider, I would like to suggest thinking about MonoLocalBinds. GHC > has a rather convincing story (at least to me) that "(local) let should not > be generalised" (since it becomes problematic in combination with several > other language extensions) and the journal version of the OutsideIn(X) paper > has empirical data that indicates it is not a big problem to remove. If > there is a concern about backwards compatibility, perhaps the committee > could deprecate local let generalisation in Haskell2020 and remove it in a > subsequent iteration of the report? FWIW, I'm against MonoLocalBinds. I understand the rational given in the paper, but I disagree with it. In my experience the medicine is worse than the disease. It used to be that where-clauses where a nice clean way of organizing code, especially for things like the worker/wrapper transform; but with MonoLocalBinds all the benefits of where-clauses are eliminated. For every local binding I'm forced to provide a type signature —because part of the whole *point* of factoring things out is that you're going to use them repeatedly, which for GADTs virtually guarantees the uses will be at different index types and therefore will require universal quantification— and these requisite type signatures almost entirely duplicate information provided by the signature for the primary/top-level binding. Indeed, in almost every situation I end up needing to manually provide type signatures which are identical to what let-generalization would have inferred. This repetition is not merely annoying, it actively harms legibility and maintainability of code. -- Live well, ~wren ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Infrastructure & Communication
Yes, persistent commenting / threading somehow on some tool. And I trust Herbert's judgement On Saturday, May 7, 2016, Vitaly Bragilevsky wrote: > The third one here. I think that process decisions can be made by chairman > alone without calling votes, that's organizing part of job, not conceptual > one. > > Vitaly > > On Sat, May 7, 2016 at 10:05 PM Richard Eisenberg > wrote: > >> I second this motion to call a vote or other concrete, forward-moving >> action on this topic. >> >> I, too, am refraining from commenting on other threads until this issue >> is resolved. >> >> Richard >> >> On May 6, 2016, at 12:32 PM, M Farkas-Dyck > > wrote: >> >> > I think we ought to make a choice quite soon. Proposals are already >> > being made on this list, but i hesitate to make comment lest it be >> > forgotten when we move to our new medium. >> > >> > My opinion on our choice of medium is known, i believe. Who or what >> > makes the final call? hvr? committee member votes? >> > ___ >> > Haskell-prime mailing list >> > Haskell-prime@haskell.org >> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime >> >> ___ >> Haskell-prime mailing list >> Haskell-prime@haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime >> > ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Infrastructure & Communication
The third one here. I think that process decisions can be made by chairman alone without calling votes, that's organizing part of job, not conceptual one. Vitaly On Sat, May 7, 2016 at 10:05 PM Richard Eisenberg wrote: > I second this motion to call a vote or other concrete, forward-moving > action on this topic. > > I, too, am refraining from commenting on other threads until this issue is > resolved. > > Richard > > On May 6, 2016, at 12:32 PM, M Farkas-Dyck wrote: > > > I think we ought to make a choice quite soon. Proposals are already > > being made on this list, but i hesitate to make comment lest it be > > forgotten when we move to our new medium. > > > > My opinion on our choice of medium is known, i believe. Who or what > > makes the final call? hvr? committee member votes? > > ___ > > Haskell-prime mailing list > > Haskell-prime@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > ___ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Infrastructure & Communication
I second this motion to call a vote or other concrete, forward-moving action on this topic. I, too, am refraining from commenting on other threads until this issue is resolved. Richard On May 6, 2016, at 12:32 PM, M Farkas-Dyck wrote: > I think we ought to make a choice quite soon. Proposals are already > being made on this list, but i hesitate to make comment lest it be > forgotten when we move to our new medium. > > My opinion on our choice of medium is known, i believe. Who or what > makes the final call? hvr? committee member votes? > ___ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Limber separators
On Saturday, May 7, 2016, Carter Schonwald
wrote:
> I worry that this thread is turning into a bit of bike shed before we have
> a good sense of what construction tools we have on hand!
>
> One side consideration we might want to keep in mind is what spaces of
> parser tech can work off the shelf in various juxtapositions of code and
> features.
>
> The more context sensitive a grammar is, the more humans Pay too!
>
> I've certainly seen agressive amounts of tuple sections in industrial
> code.
>
> Another meta question / challenge that this thread has posed is : given
> Haskell as it is today / will be in the future, is there a meaningfully
> better language tuned diff tool that could exist ?
>
>
>
> On Saturday, May 7, 2016, Kosyrev Serge <_deepf...@feelingofgreen.ru
> > wrote:
>
>> Bardur Arantsson writes:
>> > Actually, thinking about it a little further... TupleSections is already
>> > opt-in, so this needn't conflict per se.
>>
>> Isn't this dangerous, in how it now gives a trivial piece of code
>> two very different interpretations, in a plausibly unintentional way?
>>
>> > {-# LANGUAGE TupleSections #-}
>> > (x, y, ) :: t -> (a, b, t)
>>
>> > {-# LANGUAGE LaxCommas #-}
>> > (x, y, ) :: (a, b)
>>
>> I understand that we have OverloadedStrings, viz:
>>
>> > {-# LANGUAGE NoOverloadedStrings #-}
>> > "a" :: [Char]
>>
>> > {-# LANGUAGE OverloadedStrings #-}
>> > "a" :: IsString a => a
>>
>> and yet, the differences in this respect seems significant:
>>
>> The unintentionality of change in interpretation effected by the
>> transition NoOverloadedStrings -> OverloadedStrings is implausible.
>>
>> Whereas with the LaxCommas -> TupleSections transition I guess it would
>> be fair to say that it is plausible.
>>
>> Moreover, OverloadedStrings doesn't disallow using string literals as
>> string literals, whereas LaxCommas and TupleSections are mutually
>> exclusive.
>>
>> --
>> с уважениeм / respectfully,
>> Косырев Сергей
>> ___
>> Haskell-prime mailing list
>> Haskell-prime@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>>
>
My bad for forgetting to reply below rather than above :)
Tla+ does have leading AND style syntax in the style of the what is being
discussed here, but that was done from the outset.
Either way, experiments in syntax and semantics are best grounded in ...
Running experiments using them! Certainly some parts of what we hope to
achieve need to be grounded thusly, even if it's not changing the type
system or the syntax of the core substrate. Let's do some experimental
research and see what happens in the wild, in codes natural habitats! 🕵🎉
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Limber separators
I worry that this thread is turning into a bit of bike shed before we have
a good sense of what construction tools we have on hand!
One side consideration we might want to keep in mind is what spaces of
parser tech can work off the shelf in various juxtapositions of code and
features.
The more context sensitive a grammar is, the more humans Pay too!
I've certainly seen agressive amounts of tuple sections in industrial code.
Another meta question / challenge that this thread has posed is : given
Haskell as it is today / will be in the future, is there a meaningfully
better language tuned diff tool that could exist ?
On Saturday, May 7, 2016, Kosyrev Serge <_deepf...@feelingofgreen.ru> wrote:
> Bardur Arantsson > writes:
> > Actually, thinking about it a little further... TupleSections is already
> > opt-in, so this needn't conflict per se.
>
> Isn't this dangerous, in how it now gives a trivial piece of code
> two very different interpretations, in a plausibly unintentional way?
>
> > {-# LANGUAGE TupleSections #-}
> > (x, y, ) :: t -> (a, b, t)
>
> > {-# LANGUAGE LaxCommas #-}
> > (x, y, ) :: (a, b)
>
> I understand that we have OverloadedStrings, viz:
>
> > {-# LANGUAGE NoOverloadedStrings #-}
> > "a" :: [Char]
>
> > {-# LANGUAGE OverloadedStrings #-}
> > "a" :: IsString a => a
>
> and yet, the differences in this respect seems significant:
>
> The unintentionality of change in interpretation effected by the
> transition NoOverloadedStrings -> OverloadedStrings is implausible.
>
> Whereas with the LaxCommas -> TupleSections transition I guess it would
> be fair to say that it is plausible.
>
> Moreover, OverloadedStrings doesn't disallow using string literals as
> string literals, whereas LaxCommas and TupleSections are mutually
> exclusive.
>
> --
> с уважениeм / respectfully,
> Косырев Сергей
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Limber separators
Bardur Arantsson writes:
> Actually, thinking about it a little further... TupleSections is already
> opt-in, so this needn't conflict per se.
Isn't this dangerous, in how it now gives a trivial piece of code
two very different interpretations, in a plausibly unintentional way?
> {-# LANGUAGE TupleSections #-}
> (x, y, ) :: t -> (a, b, t)
> {-# LANGUAGE LaxCommas #-}
> (x, y, ) :: (a, b)
I understand that we have OverloadedStrings, viz:
> {-# LANGUAGE NoOverloadedStrings #-}
> "a" :: [Char]
> {-# LANGUAGE OverloadedStrings #-}
> "a" :: IsString a => a
and yet, the differences in this respect seems significant:
The unintentionality of change in interpretation effected by the
transition NoOverloadedStrings -> OverloadedStrings is implausible.
Whereas with the LaxCommas -> TupleSections transition I guess it would
be fair to say that it is plausible.
Moreover, OverloadedStrings doesn't disallow using string literals as
string literals, whereas LaxCommas and TupleSections are mutually
exclusive.
--
с уважениeм / respectfully,
Косырев Сергей
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Limber separators
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/05/16 10:44, Jon Fairbairn wrote: > Something that is missing from this type of discussion is any > reference to design rules, agreement on which should be made before > any suggestion like this. > > The one this violates is “never make language design decisions to > work around deficiencies in tools” I am entirely sympathetic to the argument. But I also have to read and write Haskell a lot, and to suffer from something that can seemingly be so trivially fixed *hurts*. Especially when languages like F# and Elm have taken a more practical stance and just fixed it. It's another "Haskell isn't practical/serious" argument from engineers -- and like it or not, engineers are the main users of the language. We should definitely avoid success at all costs. However, I don't think the cost is too great in this instance. Especially considering that there is already precedent for this in import and export lists. Finally, I'd like to add that I appreciate your post and angle, and hope that the committee take it to heart in general. The design should be guided by (but not slave to) first principles. - -- Alexander alexan...@plaimi.net https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJXLdMHAAoJENQqWdRUGk8BRZkQAOcxrn2oBuJMZkOsDN3vN4z7 GkeDbf4N6EB//xeQxWYvGkzcFoVLsKY6CASZ4pthRKEn0hE7EgP8q7MZOuoTECt8 fvECtpL50v43GFQ8aY6thytKkPWIPuhaN9gL5jrH5S/Q5dS4cieaxEqdh27RBSYZ FFiLlOrpVPQcuIzo2EVVVReApbatNIu3LsUXWW0wLeEjqudEVRt4yLK6WMAdSdKO C5OMuZoU2G0Cw4LOQV5tDnUfj9RS06+AJIEUUvgk7xbhU46ZaNQHqde1pTDJ3w/K Iq3g5WFndt8JZfAN/2eTLCmWj4EsX/iBMDunQqwlmAxlez5qYIgNlnlB9a7guj/n 9BT9zLuxnc/SsKB33KIkFSlVyQsssBXWOqvRcQ6ND4yi26rTLJry0WvEZ5IDmdg+ hRdKKb2YvyHLBuqMp7rIBQ7fwfCegWfJpp4A+GsCbkKXfz2SZJCBdDT3UZMkgwIQ qXr4CRESKssGXh/ezz+vXltxTAPArfDb97vULr8PeIrMoBFacIR6PVhSxHS7aSeE Hbh7zD6S6ynobtFBReQo4KYGlXUOC9nNDktnpjUAc12xQoRwVqirAasJ5D1oMwkO LB6L6YyHVlfcqb8ZfbFAHpblCCrbuw4f3pi6a9YVUy4d9ZyhX0K0RFSEWcHxE1rG yWFHxsMF+/bf7AM+tX9z =/DKF -END PGP SIGNATURE- ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Limber separators
On 05/06/2016 10:04 PM, Bardur Arantsson wrote: > [--snip--] Actually, thinking about it a little further... TupleSections is already opt-in, so this needn't conflict per se. Regards, ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Limber separators
Alexander Berntsen writes: > [ Foo > , Bar > , Fu > , Baz ] > > It is impossible to remove values Foo or Baz with a one line diff. It > is additionally impossible to reasonably add a new value to the top or > bottom of the list. I’m not on the committee either, but here’s my three haporth. Something that is missing from this type of discussion is any reference to design rules, agreement on which should be made before any suggestion like this. The one this violates is “never make language design decisions to work around deficiencies in tools” The problem is that diff does its work in ignorance of the syntax and consequently produces poor results. The other observation I want to make is that the object of programming language design is not to make writing programmes (or changing) easier. It is to make writing incorrect programmes (especially programmes that look right but are not) harder. We have to ask whether making a “one line diff” do this is actually productive. Having a large Hamming distance between syntactically valid programmes is an advantage. -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Limber separators
On 6 May 2016 20:58, "Cale Gibbard" wrote: > > If you personally want the ability to insert additional commas at the > beginning or end of lists, perhaps a better plan is to start with > asking the GHC developers with where to begin on a patch to the > parser. Then once everyone is using your extension, some future > Haskell Report can perhaps document it. +1 I would use this extension. But I strongly agree that it should start out as an extension and prove its worth in that form before becoming part of the language proper. Having Haskell' choose from the set of all available extensions is already a daunting task without opening the gates on unimplemented things too! I get the impression that many extensions that merely extend the syntax of the language are widely considered to be acceptable and seem to be on track for inclusion in H'. If this were implemented soon enough, perhaps it can make it in this time too; if not then I'm sure it'd be a candidate for a future report. I use TupleSections, and would prefer that this extension did not apply to tuples. I would also prefer to get rid of the separators completely and just use layout to delimit things, somehow. Cheers, ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
