Re: Template Haskell determinism

+1 to solving this. Not sure about the approach, but assuming the following concerns are addressed, I'm (+1) on it too: This solution is clever! However, I think there is some difficulty to determining this ordering key. Namely, what happens when I construct the (Set Name) using results from

Break Base Faster

I'm excited for the various proposals to clean up base's warts, but the time-frames over which to distribute the breaking changes are just so long---approaching a decade IIUC for Monad-Fail for example. First off, If anybody has some links to where/why the long transitions were proposed, I'd love

Re: Moving ArgumentsDo forward

Hi Bardur, On 2 June 2016 at 00:09, Bardur Arantsson wrote: > On 06/01/2016 01:48 PM, Akio Takano wrote: >> Hi, >> >> Ticket #10843 [0] proposes an extension, ArgumentsDo, which I would >> love to see in GHC. It's a small syntactic extension that allows do, >> case, if and

Re: Moving ArgumentsDo forward

This gets a guilty +1 from me, I have always found $ busy and cumbersome to read. Patterns such as ‘f a b c $ do’ are ubiquitous (especially in ESDLs where clean syntax matters more) and code such as > dataFetch req = Fetch $ \ref -> do awkwardly requires 3 steps ($, lambda, do). 2016-06-01

Re: Moving ArgumentsDo forward

Just as a note: I noticed this was being discussed a couple of weeks ago as a possible topic for haskell-prime, when they were discussing what was in scope for the committee, so I'm not entirely sure its a dead topic. -Edward On Wed, Jun 1, 2016 at 11:09 AM, Bardur Arantsson

Re: Deriving Generic1

This is a consequence of the way GHC generics represents datatypes that compose functor-like types in this fashion. If you compile that code with -ddump-deriv, you'll see that the Rep1 for Compose is (in abbreviated form): type Rep1 (Compose f g) = ... (f :.: Rec1 g) where (:.:) is defined

Re: Moving ArgumentsDo forward

On 06/01/2016 01:48 PM, Akio Takano wrote: > Hi, > > Ticket #10843 [0] proposes an extension, ArgumentsDo, which I would > love to see in GHC. It's a small syntactic extension that allows do, > case, if and lambda blocks as function arguments, without parentheses. > However, its differential

Deriving Generic1

Ryan If you compile newtype Compose f g a = Compose (f (g a)) deriving( Generic1 ) and do –show-iface on the resulting hi file, you’ll see $fGeneric1Compose :: forall (f :: * -> *) k (g :: k -> *). Functor f => Generic1 (Compose f g) I was expecting to see $fGeneric1Compose

Re: Parser changes for supporting top-level SCC annotations

I was actually trying to avoid that, thinking that it'd be best if SCC uniformly worked for top-levels and expressions. But then this new form: {-# SCC f "f_scc" #-} Would only work for toplevel SCCs.. So maybe it's OK to introduce a new pragma here. 2016-06-01 8:13 GMT-04:00 Richard

Re: Parser changes for supporting top-level SCC annotations

What about just using a new pragma? > {-# SCC_FUNCTION f "f_scc" #-} > f True = ... > f False = ... The pragma takes the name of the function (a single identifier) and the name of the SCC. If you wish both to have the same name, you can leave off the SCC name. It seems worth it to me to

Moving ArgumentsDo forward

Hi, Ticket #10843 [0] proposes an extension, ArgumentsDo, which I would love to see in GHC. It's a small syntactic extension that allows do, case, if and lambda blocks as function arguments, without parentheses. However, its differential revision [1] has been abandoned, citing a mixed response

Re: Core of a whole package

> So how do I dump the contents of a module to a .hi file? Is this > something I can do through the API? I'm not saying you can at the moment, I'm just saying usually if you need some cross-module sharing you put the stuff you want to read when compiling other files in .hi files as those files

Re: Core of a whole package

I am trying to extract information at the Core level about which functions are the most used within a package, which data types are the most used. So how do I dump the contents of a module to a .hi file? Is this something I can do through the API? Alberto On Wed, Jun 1, 2016 at 8:31 AM, Ömer

Re: Core of a whole package

You have to do your manipulations module by module, as GHC is doing compilation that way. If you need some information from other modules when compiling a module, you should dump that information in .hi files (like definitions of inline functions). What exactly are you trying to do? 2016-05-31