Re: Limber separators

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/06/16 08:44, Herbert Valerio Riedel wrote: > Well, I'd really like to see the grammar relaxed to allow for redundant > leading separators so I could finally use my personal ideal > diff-friendly style: > > something = [ > , one > ,

Re: Limber separators

On 2016-05-31 at 15:42:14 +0200, Antonio Nikishaev wrote: [...] > Personally I don't need this extension per se since I don't care about one > excess diff line. > What I do care about however, is the horrendous style people invented to > avoid “the diff problem”. > As an example > > something

Re: Limber separators

> On 12 May 2016, at 23:48, Iavor Diatchki wrote: > > > On Sat, May 7, 2016 at 1:44 AM, Jon Fairbairn > wrote: > > > The one this violates is “never make language design decisions > to work around deficiencies in tools” The problem is

Re: Limber separators

On Sat, May 7, 2016 at 1:44 AM, Jon Fairbairn wrote: > > > 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

Re: Limber separators

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/05/16 05:03, wren romano wrote: > One of my big concerns here is that the proposal is vague, and > therefore impossible to judge. It is intentionally somewhat vague because I would the committee to address this problem which is largely solved

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

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

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 >

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

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

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

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

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

Re: Limber separators

On 05/06/2016 06:34 PM, Iavor Diatchki wrote: [--snip--] > By the way, leading/trailing separators conflict with the syntax for tuple > sections: > > (True,) :: t -> (Bool, t) > (,True) :: t -> (t, Bool) > > I think that it wold be quite odd if leading/trailing commas meant one > thing in tuples

Re: Limber separators

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/05/16 21:58, 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 >

Re: Limber separators

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

Re: Limber separators

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/05/16 19:22, David Luposchainsky wrote: > Just for confirmation, you meant > >> > [ Foo >> > , Bar >> > , Fu >> > , Baz ] > and not > >> > [ Foo >> > , Bar >> > , Fu >> > , Baz >> > ] > in your email, right? Yes. The latter is how I have

Re: Limber separators

I frequently run into the (relatively minor) list comma problem when writing testsuites. I'd welcome a grammar change that simply skips all commas before "]" and after "[" or similar. I think this issue is related to TupleSections in that Haskell does not provide good syntax for these common

Re: Limber separators

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/05/16 18:34, Iavor Diatchki wrote: > I am not convinced by the argument that this will help make 'diffs' > considerably simpler: we have tools for visualizing diffs, Most people I know read plaintext patches in emails. Others use things like

Limber separators

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Haskell uses separators for values in a number of syntactic constructs. It is my understanding of the 2010 report that the language does however not generally support leading separators, nor trailing separators, nor both (two exceptions are