July 2016 - Glasgow-haskell-users

Allow extra commas in module declarations or lists?
by Michael Burge 17 Dec '16

17 Dec '16

Some languages like Perl allow you to include additional commas in your lists, so that you can freely reorder them without worrying about adding or removing commas from the last or first item: my @array = ( 1, 2, 3, ); Perl even allows multiple redundant commas everywhere after the first element, which is less useful but has come up on occasion: my @array = (1,,,2,,,,,,,,,3,,,,,); I propose allowing an optional single extra comma at the end in module declarations, record declarations, record constructors, and list constructors: module Example ( module Example, SomeConstructor(..), ) where data SomeConstructor = SomeConstructor { foo :: Int, bar :: Int, } baz :: SomeConstructor -> SomeConstructor baz x = x { foo = 5, bar = 10, } qux :: [ Int ] qux = [ 1, 2, 3, ] What do you think?

4 3

Proposal process status
by Ben Gamari 21 Jul '16

21 Jul '16

Hello everyone, As you hopefully know, a few weeks ago we proposed a new process [1] for collecting, discussing, and deciding upon changes to GHC and its Haskell superset. While we have been happy to see a small contingent of contributors join the discussion, the number is significantly smaller than the set who took part in the earlier Reddit discussions. In light of this, we are left a bit uncertain of how to proceed. So, we would like to ask you to let us know your feelings regarding the proposed process: * Do you feel the proposed process is an improvement over the status quo? * Why? (this needn't be long, just a sentence hitting the major points) * What would you like to see changed in the proposed process, if anything? That's all. Again, feel free to reply either on the GitHub pull request [1] or this thread if you would prefer. Your response needn't be long; we just want to get a sense of how much of the community feels that 1) this effort is worth undertaking, and 2) that the proposal before us is in fact an improvement over the current state of affairs. Thanks for your help! Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/pull/1

14 28

ArgumentDo proposal updated
by Akio Takano 13 Jul '16

13 Jul '16

Hi glasgow-haskell-users, Thank you for all the feedback to the ArgumentDo proposal. Following the discussion, I made changes to the proposal and updated the wiki page [0]. Now the proposed grammar is greatly simplified: it doesn't add a new non-terminal anymore, indeed it removes one instead. The proposed set of accepted programs remains unchanged. I hope the this update addresses one major concern that was raised in the previous discussion. Any feedback is appreciated. Regards, Takano Akio [0]: https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo

6 5

Rethinking GHC's approach to managing proposals
by Ben Gamari 11 Jul '16

11 Jul '16

Hello everyone, Recently there has been a fair bit of discussion[1,2] around the mechanisms by which proposed changes to GHC are evaluated. While we have something of a formal proposal protocol [3], it is not clearly documented, inconsistently applied, and may be failing to serve a significant fraction of GHC's potential contributor pool. Over the last few weeks, I have been doing a fair amount of reading, thinking, and discussing to try to piece together a proposal scheme which better serves our community. The resulting proposal [4] is strongly inspired by the RFC process in place in the Rust community [5], the leaders of which have thought quite hard about fostering community growth and participation. While no process is perfect, I feel like the Rust process is a good starting point for discussion, offering enough structure to guide new contributors through the process while requiring only a modest investment of developer time. To get a sense for how well this will work in our community, I propose that we attempt to self-host the proposed process. To this end I have setup a ghc-proposals repository [6] and opened a pull request for discussion of the process proposal [4]. Let's see how this goes. Cheers, - Ben [1] https://www.reddit.com/r/haskell/comments/4oyxo2/blog_contributing_to_ghc/ [2] https://www.reddit.com/r/haskell/comments/4isua9/ghc_development_outsidein/ [3] https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/AddingFeatures [4] https://github.com/ghc-proposals/ghc-proposals/pull/1/files?short_path=14d6… [5] https://github.com/rust-lang/rfcs [6] https://github.com/ghc-proposals/ghc-proposals

5 4

Proposal: ArgumentDo
by Akio Takano 11 Jul '16

11 Jul '16

Hi glasgow-haskell-users, I have written a wiki page about a proposed extension called ArgumentDo. It's a small syntactic extension that allows "do" expressions, lambdas and a few other kinds of expressions to be used as function arguments, without parentheses. https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo Any feedback is appreciated. In particular, since the idea has received mixed support (see the "Discussion" section on the wiki page), I'd like to make sure that there is enough support for this feature to justify an implementation in GHC. Regards, Takano Akio

15 36

Re: Glasgow-haskell-users Digest, Vol 155, Issue 9
by Ralf Hutchison 09 Jul '16

09 Jul '16

Well Iavor likes it. (see 2 below) Anyway, you know I'm really puzzled with the question of how to spend time. Maybe you can help me. In any case, it's such a lucky thing to have some to spend. Toshia and I are watching season 4 of Game of Thrones. I'm so addicted. I'm also addicted to speed chess in the same way. (I am ralf_ben_h at chess.com) I think that we have some structure in our minds, in our brains or our spines or our hearts say, and any story or game illuminates and awakens this structure. The addictive feeling or attachment is a fascination with this part of ourselves and a willingness to experience it. You wrote me a note about music recently. How are you feeling about music today? Best, Ralph On Sat, Jul 9, 2016 at 2:36 AM, <glasgow-haskell-users-request(a)haskell.org> wrote: > Send Glasgow-haskell-users mailing list submissions to > glasgow-haskell-users(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > or, via email, send a message with subject or body 'help' to > glasgow-haskell-users-request(a)haskell.org > > You can reach the person managing the list at > glasgow-haskell-users-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Glasgow-haskell-users digest..." > > > Today's Topics: > > 1. layout was Re: Proposal: ArgumentDo (C Maeder) > 2. Re: Proposal: ArgumentDo (Iavor Diatchki) > 3. Re: Proposal: ArgumentDo (C Maeder) > 4. Re: Proposal: ArgumentDo (Bardur Arantsson) > 5. Re: Proposal: ArgumentDo (Henrik Nilsson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 8 Jul 2016 14:37:04 +0200 > From: C Maeder <chr.maeder(a)web.de> > To: glasgow-haskell-users(a)haskell.org > Subject: layout was Re: Proposal: ArgumentDo > Message-ID: <577F9E70.5090300(a)web.de> > Content-Type: text/plain; charset=utf-8 > > Hi, > > the layout language options are hard to find (at least in the user > guide). Therefore I try to give an overview here. The relevant options > I've found by using ghc-7.10.3 with option --supported-languages are: > > NondecreasingIndentation > DoAndIfThenElse > > RelaxedLayout > AlternativeLayoutRule > AlternativeLayoutRuleTransitional > > I ignore the last 3 options since these seem to be candidates for > removal: https://ghc.haskell.org/trac/ghc/ticket/11359. > > The default option is NondecreasingIndentation, that is > > do > x > do > y > > is legal and parsed as a single expression "do {x ; do y}". With > -XNoNondecreasingIndentation one gets an "Empty 'do' block" for the > second do (and this error would not change with ArgumentDo!). > > DoAndIfThenElse is not switched on by default and requires the keywords > "then" and "else" to be further indented for an "if" within a "do". > > So I believe these options do not interfere with ArgumentDo, but maybe > this should be discussed more and maybe mentioned on the wiki page. > > Surely a single space (inserted before x or removed before the second > "do") makes a difference between one or two argument expressions in the > example below. > > HTH Christian > > Am 08.07.2016 um 11:20 schrieb C Maeder: > > Surely layout can bite you: > > > > f > > do > > x > > do > > y > > > > and I'm having difficulties to find the documentation for the various > > layout options. > > > > But this is no argument against this proposal! > > > > Improper use of white spaces can always be used to obfuscate code! > > Style guides are important. Furthermore, a wrong/unintended parse tree > > (due to layout) will - in many cases - result in a typing error. > > > > Christian > > > > ------------------------------ > > Message: 2 > Date: Fri, 8 Jul 2016 09:42:24 -0700 > From: Iavor Diatchki <iavor.diatchki(a)gmail.com> > To: Aloïs Cochard <alois.cochard(a)gmail.com> > Cc: GHC users <glasgow-haskell-users(a)haskell.org>, Henrik Nilsson > <Henrik.Nilsson(a)nottingham.ac.uk> > Subject: Re: Proposal: ArgumentDo > Message-ID: > <CAGK9nuo93t=- > g9FktDG37iE7EeFwW6P5w5GOud3dmQkHA8oukg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello, > > while we are voting here, I kind of like this proposal, so +1 for me. > > I understand that some of the examples look strange to Haskell old-timers > but, as Joachim points out, the behavior is very consistent. Besides, the > "Less Obvious Examples" were selected so that they are, well, less obvious. > The common use cases (as in ticket #10843) seem quite appealing, at least > to me, and not at all confusing. But, then, I also like the > records-with-no-parens notation :-) > > -Iavor > > > > On Fri, Jul 8, 2016 at 5:03 AM, Aloïs Cochard <alois.cochard(a)gmail.com> > wrote: > > > -1 for same reasons. > > > > On 8 July 2016 at 14:00, Henrik Nilsson <Henrik.Nilsson(a)nottingham.ac.uk > > > > wrote: > > > >> Hi all, > >> > >> Joachim Breitner wrote: > >> > >> > Am Freitag, den 08.07.2016, 13:09 +0200 schrieb Sven Panne: > >> > > I don't think so: https://ghc.haskell.org/trac/ghc > >> > /wiki/ArgumentDo#Bl > >> > [...] > >> > Where is the outer set of parenthesis coming from? > >> > > >> > This is all not related to the ArgumentDo notation. Note that [...] > >> > >> The very fact that that experts can't easily agree on how a small > >> Haskell fragment is parsed to me just confirms that Haskell already > >> is a syntactically very cumbersome language. > >> > >> The present proposal just makes matters worse. For that reason > >> alone, I don't find it compelling at all. (So -1 from me, then.) > >> > >> I will not repeat the many other strong arguments against that has been > >> made. But I must say I don't find the use cases as documented > >> on the associated web page compelling at all. Maybe there is a tacit > >> desire to be able to pretend functions are keywords for various > >> creative uses in supporting EDSLs and such. But for that to be truly > >> useful, one need to support groups of related keywords. Something > >> like Agda's mixfix syntax springs to mind. But this proposal does > >> not come close, so the benefits are minimal and the drawbacks large. > >> > >> As a final point, the inherent asymmetry of the proposal (the > >> last argument position is special as, for certain kinds of > >> expressions, parentheses may be omitted there but not elsewhere) > >> is also deeply unsettling. > >> > >> Best, > >> > >> /Henrik > >> > >> -- > >> Henrik Nilsson > >> School of Computer Science > >> The University of Nottingham > >> nhn(a)cs.nott.ac.uk > >> > >> > >> > >> > >> This message and any attachment are intended solely for the addressee > >> and may contain confidential information. If you have received this > >> message in error, please send it back to me, and immediately delete it. > >> Please do not use, copy or disclose the information contained in this > >> message or in any attachment. Any views or opinions expressed by the > >> author of this email do not necessarily reflect the views of the > >> University of Nottingham. > >> > >> This message has been checked for viruses but the contents of an > >> attachment may still contain software viruses which could damage your > >> computer system, you are advised to perform your own checks. Email > >> communications with the University of Nottingham may be monitored as > >> permitted by UK legislation. > >> > >> _______________________________________________ > >> Glasgow-haskell-users mailing list > >> Glasgow-haskell-users(a)haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > >> > > > > > > > > -- > > *Λ\oïs* > > http://twitter.com/aloiscochard > > http://github.com/aloiscochard > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users(a)haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > > > >

1 1

Space-leak incurred by constraints
by Christiaan Baaij 06 Jul '16

06 Jul '16

Hi, The following reduced test-case: > {-# LANGUAGE DataKinds, TypeOperators, TypeFamilies, ConstraintKinds, > FlexibleContexts, BangPatterns #-} > module ConstraintLeak where > > import GHC.TypeLits > import Data.Proxy > > type Constraint1 n > = ( Constraint2 n > , Constraint2 (2^n) > ) > type Constraint2 n > = ( KnownNat n > , ((n-1)+1) ~ n -- Comment this line to run in constant space > ) > > test :: Constraint1 x => Proxy x -> String > test !s | s == s = test s > > main :: IO () > main = putStr (test (Proxy :: Proxy 3)) contains a space-leak when compiled without optimisations (i.e. -O0 or in GHCi). It's true that the code doesn't actually do anything (when compiled with -O you get "Exception <<loop>>"), but I'm using it to exemplify some code that runs for some time, and then prints something. As you can see, 'test' is strict in its arguments, but it seems lazy in its constraints. When I look at the heap profile (-hy), I see it rapidly accumulating values of the following types: - ~ - KnownNat - (,) The problem with these constraints, unlike a normal type-class constraints, is that I cannot 'seq' one of its members to force the dictionary and hence be strict in the constraints. We stumbled upon this particular space-leak while trying to find a space-leak in our own code; we don't think it's the real culprit in our own code, but find it disturbing nonetheless. GHCi is heavily used in our work-flow, meaning we often run in an -O0 setting, so I would like to know if it is possible to plug this constraint-induced space-leak. Regards, Christiaan Baaij

1 0