- Glasgow-haskell-users

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

CMM-to-ASM: Register allocation wierdness
by Harendra Kumar 26 Jun '16

26 Jun '16

Hi, I am implementing unicode normalization in Haskell. I challenged myself to match the performance with the best C/C++ implementation, the best being the ICU library. I am almost there, beating it in one of the benchmarks and within 30% for others. I am out of all application level tricks that I could think of and now need help from the compiler. I started with a bare minimum loop and adding functionality incrementally watching where the performance trips. At one point I saw that adding just one 'if' condition reduced the performance by half. I looked at what's going on at the assembly level. Here is a github gist of the assembly instructions executed in the fast path of the loop, corresponding cmm snippets and also the full cmm corresponding to the loop: https://gist.github.com/harendra-kumar/7d34c6745f604a15a872768e57cd2447 I have annotated the assembly code with labels matching the corresponding CMM. With the addition of another "if" condition the loop which was pretty simple till now suddenly got bloated with a lot of register reassignments. Here is a snippet of the register movements added: # _n4se: # swap r14 <-> r11 => 0x408d6b: mov %r11,0x98(%rsp) => 0x408d73: mov %r14,%r11 => 0x408d76: mov 0x98(%rsp),%r14 # reassignments # rbx -> r10 -> r9 -> r8 -> rdi -> rsi -> rdx -> rcx -> rbx => 0x408d7e: mov %rbx,0x90(%rsp) => 0x408d86: mov %rcx,%rbx => 0x408d89: mov %rdx,%rcx => 0x408d8c: mov %rsi,%rdx => 0x408d8f: mov %rdi,%rsi => 0x408d92: mov %r8,%rdi => 0x408d95: mov %r9,%r8 => 0x408d98: mov %r10,%r9 => 0x408d9b: mov 0x90(%rsp),%r10 . . . loop logic here which uses only %rax, %r10 and %r9 . . . . # _n4s8: # shuffle back to original assignments => 0x4090dc: mov %r14,%r11 => 0x4090df: mov %r9,%r10 => 0x4090e2: mov %r8,%r9 => 0x4090e5: mov %rdi,%r8 => 0x4090e8: mov %rsi,%rdi => 0x4090eb: mov %rdx,%rsi => 0x4090ee: mov %rcx,%rdx => 0x4090f1: mov %rbx,%rcx => 0x4090f4: mov %rax,%rbx => 0x4090f7: mov 0x88(%rsp),%rax => 0x4090ff: jmpq 0x408d2a The registers seem to be getting reassigned here, data flowing from one to the next. In this particular path a lot of these register movements seem unnecessary and are only undone at the end without being used. Maybe this is because these are reusable blocks and the movement is necessary when used in some other path? Can this be avoided? Or at least avoided in a certain fast path somehow by hinting the compiler? Any pointers to the GHC code will be appreciated. I am not yet much familiar with the GHC code but can dig deeper pretty quickly. But before that I hope someone knowledgeable in this area can shed some light on this at a conceptual level or if at all it can be improved. I can provide more details and experiment more if needed. Thanks, Harendra

5 12

TDNR without new operators or syntax changes
by Jeremy 22 Jun '16

22 Jun '16

Previous attempts to propose TDNR [1] have met with opposition over the accompanying proposal to change the syntax of the dot or add a new operator for postfix application. However, nothing about TDNR - other than certain motivating examples - actually requires changes to the syntax of Haskell or new operators. TDNR could be implemented as an extension which just give GHC a new way of disambiguating function names, and nothing else. This would still have some advantages: - Redundant module qualification no longer required. - Unqualified imports could be changed to a different module with the same interface (a very poor-man's backpack) without any other code changes. - People who want TDNR with postfix function application will only need to define a simple postfix operator. I would therefore like to propose TNDR without any syntax/prelude changes. [1] https://prime.haskell.org/wiki/TypeDirectedNameResolution -- View this message in context: http://haskell.1045720.n5.nabble.com/TDNR-without-new-operators-or-syntax-c… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

4 9

Simon's email classified as spam
by Simon Peyton Jones 19 Jun '16

19 Jun '16

Dear GHC devs/users This is another test to see if email from me, relayed via Haskell.org, ends up in your spam folder. Gershom thinks he’s fixed it (below). Can I trespass on your patience once more? Just let me know if this email ends up in your inbox or spam. Can you cc John and Gershom (but perhaps not everyone else)? Thanks Simon | From: Gershom B [mailto:gershomb@gmail.com] | Sent: 18 June 2016 18:53 | To: Simon Peyton Jones <simonpj(a)microsoft.com>; John Wiegley | <johnw(a)newartisans.com> | Cc: Michael Burge <michaelburge(a)pobox.com> | Subject: Re: FW: CMM-to-SAM: Register allocation weirdness | | Simon — I just found two possible sources of the problem (first: the top | level config didn’t take hold due to other errors when updating — fixed that, | and second, it might be possible the top level config isn’t retroactively | applied to all lists — so i added the config to the relevant lists directly). | | I think if you try one more time it might work (fingers crossed).

3 2

RE: CMM-to-ASM: Register allocation wierdness
by Simon Peyton Jones 19 Jun '16

19 Jun '16

Takenobu, and others Thanks. Several people have mentioned that email from me is ending up in spam. It turns out to be a fault in the Haskell.org mailman setup, which was mis-forwarding my email. Apparently it is fixed now. If THIS message ends up in spam with a complaint like that below, could you let me know? Thanks Simon From: Takenobu Tani [mailto:takenobu.hs@gmail.com] Sent: 18 June 2016 08:18 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Re: CMM-to-ASM: Register allocation wierdness Hi Simon, I report to you about your mails. Maybe, your mails don't reach to Gmail users. I don't know why, but your mails have been distributed to "Spam" folder in Gmail. Gmail displays following message: "Why is this message in Spam? It has a from address in microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmicrosoft.c…> but has failed microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmicrosoft.c…>'s required tests for authentication." For reference, I attach the screen of my Gmail of spam folder. Recent your mails have been detected as spam. Please check your mail settings. Regards, Takenobu 2016-06-16 21:10 GMT+09:00 Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>>: | All-in-all, the graph coloring allocator is in great need of some love; | Harendra, perhaps you'd like to have a try at dusting it off and perhaps | look into why it regresses in compiler performance? It would be great if | we could use it by default. I second this. Volunteers are sorely needed. Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org<mailto:Glasgow-haskell-users@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskel…>

4 4