- ghc-devs - Haskell.org

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

macOS 10.12
by Manuel M T Chakravarty 29 Jul '16

29 Jul '16

Has anybody tried compiling GHC with the (beta) macOS 10.12 Sierra SDK? I just gave it a shot trying to compile GHC 7.8.3 and ran into a problem with GetTime.c in the RTS. (I haven’t tried GHC 8.0.1.) Manuel

3 4

Re: atomicModifyMutVar#: cas() is not inlined
by Ömer Sinan Ağacan 27 Jul '16

27 Jul '16

To keep this thread up-to-date: https://phabricator.haskell.org/D2431 2016-07-27 14:08 GMT+00:00 Alex Biehl <alex.biehl(a)gmail.com>: > There already is the CallishMachOp MO_cmpxchg in > https://github.com/ghc/ghc/blob/5d98b8bf249fab9bb0be6c5d4e8ddd4578994abb/co… > > All is left todo would be to add it to CmmParse.y (which has a TODO comment > https://github.com/ghc/ghc/blob/714bebff44076061d0a719c4eda2cfd213b7ac3d/co…) > then you could use that instead of the ccall. > > Ömer Sinan Ağacan <omeragacan(a)gmail.com> schrieb am Mi., 27. Juli 2016 um > 11:15 Uhr: >> >> This is from definition of stg_atomicModifyMutVarzh(): (for threaded >> runtime) >> >> retry: >> x = StgMutVar_var(mv); >> StgThunk_payload(z,1) = x; >> (h) = ccall cas(mv + SIZEOF_StgHeader + OFFSET_StgMutVar_var, x, y); >> if (h != x) { goto retry; } >> >> cas() is defined in includes/stg/SMP.h like this: >> >> EXTERN_INLINE StgWord >> cas(StgVolatilePtr p, StgWord o, StgWord n) >> { >> return __sync_val_compare_and_swap(p, o, n); >> } >> >> I think this is a function we want to make sure to inline everywhere, >> right? >> It's compiled to a single instruction on my x86_64 Linux laptop. >> >> >>> disassemble cas >> Dump of assembler code for function cas: >> 0x0000000000027240 <+0>: mov %rsi,%rax >> 0x0000000000027243 <+3>: lock cmpxchg %rdx,(%rdi) >> 0x0000000000027248 <+8>: retq >> End of assembler dump. >> >> But it seems like it's not really inlined in Cmm functions: >> >> >>> disassemble stg_atomicModifyMutVarzh >> Dump of assembler code for function stg_atomicModifyMutVarzh: >> ... >> 0x0000000000046738 <+120>: callq 0x27240 <cas> >> ... >> End of assembler dump. >> >> I guess the problem is that we can't inline C code in Cmm, but I was >> wondering >> if this is important enough to try to fix maybe. Has anyone here looked at >> some >> profiling info to see how much time spent on this cas() call when threads >> are >> blocked in `atomicModifyIORef` etc? >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

atomicModifyMutVar#: cas() is not inlined
by Ömer Sinan Ağacan 27 Jul '16

27 Jul '16

This is from definition of stg_atomicModifyMutVarzh(): (for threaded runtime) retry: x = StgMutVar_var(mv); StgThunk_payload(z,1) = x; (h) = ccall cas(mv + SIZEOF_StgHeader + OFFSET_StgMutVar_var, x, y); if (h != x) { goto retry; } cas() is defined in includes/stg/SMP.h like this: EXTERN_INLINE StgWord cas(StgVolatilePtr p, StgWord o, StgWord n) { return __sync_val_compare_and_swap(p, o, n); } I think this is a function we want to make sure to inline everywhere, right? It's compiled to a single instruction on my x86_64 Linux laptop. >>> disassemble cas Dump of assembler code for function cas: 0x0000000000027240 <+0>: mov %rsi,%rax 0x0000000000027243 <+3>: lock cmpxchg %rdx,(%rdi) 0x0000000000027248 <+8>: retq End of assembler dump. But it seems like it's not really inlined in Cmm functions: >>> disassemble stg_atomicModifyMutVarzh Dump of assembler code for function stg_atomicModifyMutVarzh: ... 0x0000000000046738 <+120>: callq 0x27240 <cas> ... End of assembler dump. I guess the problem is that we can't inline C code in Cmm, but I was wondering if this is important enough to try to fix maybe. Has anyone here looked at some profiling info to see how much time spent on this cas() call when threads are blocked in `atomicModifyIORef` etc?

1 0

Re-exporting traverse_ from Data.Traversable
by Christopher Allen 26 Jul '16

26 Jul '16

Any reason not to do it? I realize it needs Foldable, but even knowing that I still forget it's in Data.Foldable. Seems like a free UX win to me.

2 1

Supporting unboxed tuples in the bytecode compiler
by Ömer Sinan Ağacan 25 Jul '16

25 Jul '16

Simon, I was looking at the bytecode compiler to understand what's needed to support unboxed tuples. It seems like if we generate bytecode after unarise it should be very easy to support unboxed tuples, because after unarise we don't have any unboxed tuple binders (all binders have UnaryType). So only places we see unboxed tuples are: - Return positions. We just push contents of the tuple to the stack. - Case alternatives. The case expression in this case has to have this form: case e1 of (# bndr1, bndr2, ..., bndrN #) -> RHS All binders will have unary types again. We just bind ids in the environment to their stack locations and compile RHS. I think that's it. We also get unboxed sums support for free when we do this after unarise. What do you think about compiling to bytecode from STG? Have you considered that before? Would that be a problem for GHCi's debugger or any other features?

2 1