- ghc-devs - Haskell.org

Can we offer ~ without GADTs or type families?
by David Feuer 06 Aug '16

06 Aug '16

It seems to me that equality constraints could potentially be supported by an implementation with neither GADTs nor type families. Type families don't really seem to have much to do with it, and GADTs are strictly heavier (GADTs ~= ExistentialQuantification + TypeEquality). Could we get a separate LANGUAGE pragma just for equality constraints?

3 2

Re: [commit: ghc] master: Replace some `length . filter` with `count` (02614fd)
by Joachim Breitner 06 Aug '16

06 Aug '16

Hi, Am Freitag, den 05.08.2016, 22:41 +0000 schrieb git(a)git.haskell.org: > commit 02614fd61f57b599c5e4fd5e85f00a4e1ce37bc7 > Author: Ömer Sinan Ağacan <omeragacan(a)gmail.com> > Date: Fri Aug 5 20:58:02 2016 +0000 > > Replace some `length . filter` with `count` Well intended! I wouldn’t be surprised if this is actually making the code worse, considering that "count" is implemented in the “wrong”, stackeating way (whereas lenght . filter could, thanks to list fusion, produce the desired code) count :: (a -> Bool) -> [a] -> Int count _ [] = 0 count p (x:xs) | p x = 1 + count p xs | otherwise = count p xs I would say that the regression reported by https://perf.haskell.org/ghc/#revision/02614fd61f57b599c5e4fd5e85f00a4e1ce3… confirms this, but T6048 is simply unreliable. So practically, it does not seem to matter either way. I’ll change the implementation of count. (Although even then it is not clear that the change is a win, as "length . filter" might fuse with the producer, whereas "count" without a lot of extra hassle will not.) Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0

Re: Can we offer ~ without GADTs or type families?
by Ryan Scott 05 Aug '16

05 Aug '16

Hi David, > Could we get a separate LANGUAGE pragma just for equality constraints? I think we should, and I don't think we'd even need to introduce a new pragma, since there's already a perfectly good one: -XTypeOperators! After all, there's nothing really that special about (~) other than some typechecking details. A fix to Trac #9194 [1] would give us this. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/9194

2 2

Deriving tweaking
by David Feuer 05 Aug '16

05 Aug '16

I know there's been some discussion about letting users select the deriving mechanism they want, but I'd like to propose a separate tweak to the defaults. Specifically, it's annoying to have to use three pragmas to let me write newtype Foo f a = Foo (f a) deriving (Functor, Foldable, Traversable) data Bar f a = Bar (f a) deriving (Functor, Foldable, Traversable) and more annoying still that I'll end up with Foldable and Functor instances for Foo that may be much worse than GND-derived ones. The tweaks I'm after: 1. Prefer GND to the built-in derivations for Functor and Foldable, and probably also Eq and Ord. 2. Make DeriveTraversable imply DeriveFunctor and DeriveFoldable.

2 2

Re: Deriving tweaking
by Ryan Scott 05 Aug '16

05 Aug '16

You're in luck, David, since both of your requests are currently things that GHC will do. Specifically, > 1. Prefer GND to the built-in derivations for Functor and Foldable, and probably also Eq and Ord. GHC will always derive Eq and Ord instances for newtypes using GND, and will prefer GND when deriving Functor and Foldable instances for newtypes when (1) the -XGeneralizedNewtypeDeriving extension is on, and (2) eta-reducing the type variable is allowed. See [1] for the full details on how GHC chooses when to pick GND behind the scenes. > 2. Make DeriveTraversable imply DeriveFunctor and DeriveFoldable. That's already the case, thanks to Trac #9069. [2] Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategie… [2] https://ghc.haskell.org/trac/ghc/ticket/9069

1 0

Re: Request for feedback: deriving strategies syntax
by Ryan Scott 05 Aug '16

05 Aug '16

Sorry for not including the full context on that link. It's part of a Summer of Haskell 2016 project called Native Metaprogramming in Haskell [1] (a.k.a. Introspective Template Haskell [2]), aiming to fix Trac #11081 [3]. Ryan S. ----- [1] https://github.com/shayan-najd/NativeMetaprogramming [2] https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Introspective [3] https://ghc.haskell.org/trac/ghc/ticket/11081

4 3

Re: Request for feedback: deriving strategies syntax
by Ryan Scott 04 Aug '16

04 Aug '16

> How much of this derivation machinery could NOT be implemented by means of > some kind of a (hypothetical) type-backed metaprogramming facility? I think this would be a wonderful thing to have. Matthew Pickering (cc'd) has expressed a desire to have all the logic for the `bespoke` deriving strategies compartmentalized into a library that could easily be expanded on in the future to support more typeclasses in base. (Bifunctor, anyone?) Unfortunately, each of the major players in today's Haskell metaprogramming scene that I'm aware of have some downfalls that make them unsuitable as `deriving` replacements: * Template Haskell: Not portable. Staging issues make it hard to use as a drop-in replacement for the `deriving` keyword * GHC generics: Can't express all the optimizations that the bespoke `deriving` algorithms perform. Unperformant. * Haskell preprocessors: Difficult to integrate in a typical GHC workflow. Probably wouldn't have all the metadata you'd need to be feature-complete with what `deriving` does today. The way I see it, the whole `deriving` business as it currently stands today is a somewhat-grotesque-but-darn-useful hack that gets around the lack of a truly nice metaprogramming facility in Haskell. I'm holding out hope that the work in https://github.com/shayan-najd/NativeMetaprogramming makes things nicer soon, and then we can revisit this idea. Until then, -XDerivingStrategies provides a way to contain some of the madness of `deriving` after having many features tacked onto it in recent GHC releases. Ryan S.

5 5

Re: Request for feedback: deriving strategies syntax
by Ryan Scott 03 Aug '16

03 Aug '16

That is a good question. Weirdly enough, the current behavior for how a deriving strategy is resolved (without explicit keywords) isn't really documented anywhere, so I attempted to figure out what GHC currently does and documented it here [1]. I'll reproduce the algorithm (including deriving strategies) below: 1. Look for a deriving strategy. If one is present, use that. 2. (a) If deriving an `Eq`, `Ord`, `Ix`, or `Bounded` instance for a newtype, use the `GeneralizedNewtypeDeriving` strategy (even if the language extension isn't enabled). (b) If deriving a `Read`, `Show`, `Data`, `Generic`, `Generic1`, `Typeable`, `Traversable`, or `Lift` instance for a newtype, go to step 3. (c) Otherwise, if deriving a "standard derivable class" (e.g., `Eq`, `Ord`, `Generic`, etc.) instance for a newtype, and `-XGeneralizedNewtypeDeriving` is enabled, derive the class using the `GeneralizedNewtypeDeriving` strategy. (d) Otherwise, if deriving an instance for a newtype and both `-XGeneralizedNewtypeDeriving` and `-XDeriveAnyClass` are enabled, default to `DeriveAnyClass`, but emit a warning stating the ambiguity. (e) Otherwise, if deriving an instance for a newtype, the datatype and typeclass can be successfully used with `GeneralizedNewtypeDeriving`, and `-XGeneralizedNewtypeDeriving` is enabled, do so. 3. (a) If deriving a "standard derivable class" (e.g., `Eq`, `Ord`, `Generic`, etc.) and the corresponding language extension is enabled (if necessary), do so. If the language extension is not enabled, throw an error. (b) Otherwise, if `-XDeriveAnyClass` is enabled, use that. (c) Otherwise, throw an error. This is quite ugly, but to my knowledge this is currently what GHC does (excluding 2(c), which is a bit that fixes a bug reported in Trac #10598 [2]), so there shouldn't be any change in behavior from before. This is another good reason to want deriving strategies: trying to remember all of that is nearly impossible! Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategie… [2] https://ghc.haskell.org/trac/ghc/ticket/10598 On Wed, Aug 3, 2016 at 11:53 AM, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: > >> On Aug 2, 2016, at 6:59 PM, Ryan Scott <ryan.gl.scott(a)gmail.com> wrote: >> Any other questions or comments? >> > > Yes, a question: What is the behavior if no keyword is given? Any change here from the status quo is quite dangerous from a backward-compatibility standpoint, but I wonder if we could start issuing warnings/errors in a few years. > > Richard >

2 2

A function with absent demand on syntactically used argument?
by Ömer Sinan Ağacan 03 Aug '16

03 Aug '16

I'm reading the code in WwLib that generates worker functions and I'm confused about absent lets. Can anyone give an example function that has absent demand on its argument even though the argument is syntactically used in the body? I think we should add some examples to `Note [Absent errors]` in WwLib.hs. One example came to my mind was something like f x = ... undefined x ... I'm guessing that if we were to generate a worker for this, we'd need to generate an absent let for x in the worker function. But "undefined" has a weird (polymorphic over both function and non-function types) type and I don't know what's the demand signature of it (maybe we should document this too), so I'm not sure.

2 1

FINAL CALL FOR TALKS (Aug 8 deadline): Haskell Implementors Workshop 2016, Sep 24, Nara
by Edward Z. Yang 01 Aug '16

01 Aug '16

Deadline is in a week! Submit your talks! Call for Contributions ACM SIGPLAN Haskell Implementors' Workshop http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2016 Nara, Japan, 24 September, 2016 Co-located with ICFP 2016 http://www.icfpconference.org/icfp2016/ Important dates --------------- Proposal Deadline: Monday, 8 August, 2016 Notification: Monday, 22 August, 2016 Workshop: Saturday, 24 September, 2016 The 8th Haskell Implementors' Workshop is to be held alongside ICFP 2016 this year in Nara. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings; the workshop will be informal and interactive, with a flexible timetable and plenty of room for ad-hoc discussion, demos, and impromptu short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2016. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. In the Haskell Implementors' Workshop, we hope to study the underlying technology. We want to bring together anyone interested in the nitty-gritty details behind turning plain-text source code into a deployed product. Having said that, members of the wider Haskell community are more than welcome to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- At this stage we would like to invite proposals from potential speakers for talks and demonstrations. We are aiming for 20 minute talks with 10 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions should be made via HotCRP. The website is: https://icfp-hiw16.hotcrp.com/ We will also have a lightning talks session which will be organised on the day. These talks will be 5-10 minutes, depending on available time. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Organisers --- End forwarded message ---

1 0