- Haskell-prime - Haskell.org

Infrastructure status?
by Iavor Diatchki 01 Jun '16

01 Jun '16

Hello, what is the status of the discussion about how we should collaborate? I am not picky and would be happy to use whatever tools others prefer. If it was left to me, I'd use: 1) a git repo on github, which contains the current version of the report, and various proposals, and 2) this e-mail list for discussion. As I said before, I think it might be quite nice as a first step to standardize something simple, and hopefully not too controversial, so that we can all familiarize ourselves with the basic process. -Iavor

3 3

New Proposal: EasyMacros
by Anton Felix Lorenzen 18 May '16

18 May '16

Hello list, I want to propose a new way of writing template-haskell macros. It is based on the idea, that syntax like this: do { x <- getLine; putStrLn x; } should be parsed into: $( do [ [| x <- getLine |] , [| putStrLn x |] ] ) Then a function (do :: NonEmpty ExpQ -> ExpQ) will be called and executed. This would allow for a couple of useful macros: - do - case - fold -- fold the ExpQs into one, see below for details - eval -- evaluate ExpQs at compile-time - (maybe even) hamlet -- evaluate hamlet QQ - CPP replacements? Nothing will be added which isn't possible today. Nonetheless it will allow for a much cleaner syntax and by this make things usable which weren't usable before. Also it might be easier to implement new features. For example ApplicativeDo and RecursiveDo could have been implemented by a hackage package. MultiWayIf could be a function, too. apply [1..(10*365)] map (replicate 3) concat conc "Hello World! \n" "How are you? \n" Greetings, Anton ===== Example Macros ===== see in context: https://github.com/anfelor/EasyMacros conc = fold [| (++) |] apply = fold [|flip ($)|] fold :: ExpQ -- (a -> b -> c) -> NonEmpty (Q Exp) -> Q Exp fold _ (a :| []) = a fold fn (a :| b : xs) = fold fn (([| fn $a $b |]) :| xs) do_ :: NonEmpty (Q Stmt) -> Q Exp do_ (x :| []) = x >>= \case BindS _ _ -> fail "The last statement in a 'do' block must be an expression" NoBindS e -> return e do_ (x :| xs) = x >>= \case BindS pat exp -> [| $(return exp) >>= \ $(return pat) -> $(do_ (fromList xs)) |] NoBindS exp -> [| $(return exp) >> $(do_ (fromList xs)) |]

2 1

Chairship / responsibility
by Richard Eisenberg 09 May '16

09 May '16

Hi Prime, Is there a chair of this committee? Herbert has been acting as such (thank you!) but doesn't list himself as the chair in the initial announcement. I am **in no way** trying to change any status quo and am **not** interested in being chair at the moment, but I just wanted to clarify. The specific reason I ask is that Takenobu Tani recently asked about `pseq`. I have no intelligent response to offer, but would want to make sure that someone does offer a response. If there is a chair, that person is de facto responsible that we, as a committee, communicate well, both internally and externally. Thanks, Richard

11 11

Infrastructure & Communication
by Herbert Valerio Riedel 09 May '16

09 May '16

Hello Fellow Committee Members! Following up on the official announcement, here's a few basic things we should get agreement over before proceeding. First off, I'm hoping we can manage to avoid confusing email-threading in the interest of finding information easier lateron in the email archives. To this end, I'd like to ask you to consider changing the subject of your reply if you realise that the topic discussed is diverging significantly from the one advertised in the Subject-header. I'll start with the following basic topic ## Infrastructure & Communication Obviously, we have *this* public (archived) mailing list "haskell-prime(a)haskell.org". There's also a (registered) IRC channel "#haskell-prime" on freenode where many of us will probably hang around. In the past, the Prime committee used Trac (currently at https://prime.haskell.org/ ) to organise its work. Trac provides a wiki, source-browser, and a ticket tracker (which is familiar to GHC developers, and e.g. allows easy migration of wiki-content to/from the GHC Wiki). Some time ago, I converted the original Haskell-Report Darcs repositories into a single Git repository (with branches) at GitHub - https://github.com/haskell/haskell-report This repo is setup to be mirrored to - https://git.haskell.org/haskell-report.git which in turn is also accessible from within Trac at - https://prime.haskell.org/browser However, since Trac has accumulated quite a bit of old content in its ticket-tracker over the years, and "Haskell 2020" has been coined a reboot. Maybe it wouldn't be such a bad idea to start over at GitHub, and consider the Trac instance mostly as a legacy archive of historic content. GitHub allows for Git-based workflows, and there's prior art related to language design we could steal ideas from, for instance: - https://github.com/fsharp/FSharpLangDesign - https://github.com/rust-lang/rfcs - https://github.com/golang/proposal - (any others noteworthy?) IMO, GitHub's issue tracker has become flexible enough for our needs and its integration with Git pull-requests allows to e.g. group together change proposal description/motivation, discussion, and finaly the delta to the haskell-report (with inline annotations/reviews) and so on. (However, I consider GitHub's Wiki-component quite weak. I'm not sure what to do about that. Maybe keep using Trac's wiki for that?) Moreover, we can have CI (I've actually set up a TravisCI job which builds the LaTeX code) for the Haskell Language report drafts. One benefit I see from using GitHub is that this way would we be closer to the Haskell community (given the majority of Hackage packages are hosted on GitHub), and our work would be more transparent for the community as well as offering a lower barrier to participation/contribution. Moreover, I think GitHub would also help make our efforts/progress towards a revised Haskell Report more visible to the community, which in turn may even provide us the motivation to carry on... So... Does anyone object to using GitHub? In case there's no objection, which of the existing language-design GitHub projects do you consider a good fit for Haskell Prime and therefore worthy of imitation? Any other comments/suggestions? Cheers, HVR

16 20

The GADT debate
by wren romano 09 May '16

09 May '16

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

6 8

Are there GHC extensions we'd like to incorporate wholesale?
by John Wiegley 09 May '16

09 May '16

I wonder if there are GHC extensions we'd like to promote as features in the next report, as a starting point for discussing new additions. There are a few GHC features that have become part of the regular Haskell landscape, such that it's hard to imagine a modern Haskell without them. For example, MultiParamTypeClasses, OverloadedStrings, GADTs, TypeFamilies, etc. How much "work" is typically involved in promoting a feature to be in the Report, and how do we determine when it's a bad idea? -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2

17 25

Starting point for new standard?
by Christian Siefkes 04 May '16

04 May '16

Hi all, out of curiosity, what'll be the starting point for the next Haskell report? I suppose Haskell 2010 plus the additional "No Datatype Contexts" change accepted by the old Haskell Language committee in early 2011 (see https://wiki.haskell.org/Haskell_2010#Additional_change )? Best regards Christian -- |--------- Dr. Christian Siefkes --------- christian(a)siefkes.net --------- | Homepage: http://www.siefkes.net/ | Blog: http://www.keimform.de/ | Wie Produktion zur Nebensache wurde: www.keimform.de/2013/freie-quellen-1/ | Why Production No Longer Worries Us: www.keimform.de/2013/free-sources-1/ |------------------------------------------- OpenPGP Key ID: 0x980FA6ED -- 2 + 2 = 5 for suitably large values of 2.

2 1

Re: Are there GHC extensions we'd like to incorporate wholesale?
by Doug McIlroy 03 May '16

03 May '16

> One objective would be to compile the Haskel Platform with near zero extensions. I would hope that means that the platform will lean on contributors to observe the new standard and curb exuberant use of extensions. It would be wrong to blindly accept a selected corpus of existing code as basis for a standard. (This is not to say that haskell prime should ignore the practices of outstanding packages.) Doug

1 0

Evaluation order control between two expressions
by Takenobu Tani 30 Apr '16

30 Apr '16

Dear Community, Apologies if I'm missing context. Does Haskell 2020 specify evaluation order control by `pseq`? We use `pseq` to guarantee the evaluation order between two expressions. But Haskell 2010 did not specify how to control the evaluation order between two expressions. (only specified `seq` in Haskell 2010 section 6.2 [1]. but `seq` don't guarantee the order. [2]) I think it's better to explicitly specify `pseq` as standard way. Already discussed? or out of scope? [1]: https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-126000… [2]: https://www.schoolofhaskell.com/user/snoyberg/general-haskell/advanced/eval… Regards, Takenobu

6 10

Re: Chairship / responsibility
by wren romano 29 Apr '16

29 Apr '16

> Hi Prime, > > Is there a chair of this committee? Herbert has been acting as such (thank you!) but doesn't list himself as the chair in the initial announcement. I am **in no way** trying to change any status quo and am **not** interested in being chair at the moment, but I just wanted to clarify. > > The specific reason I ask is that Takenobu Tani recently asked about `pseq`. I have no intelligent response to offer, but would want to make sure that someone does offer a response. If there is a chair, that person is de facto responsible that we, as a committee, communicate well, both internally and externally. I don't know that we have one (officially), but I agree that getting/agreeing-on one should be done soon. -- Live well, ~wren

1 0