Re: Repeated computations under a lambda

2017-07-18 Thread Joachim Breitner
Hi, Am Dienstag, den 18.07.2017, 17:01 -0700 schrieb Conal Elliott: > Here's the code in question, slightly rephrased: > > > exampleC t = \ x -> x + s where s = sin t > > I wrote it this way so that `sin t` would be computed once per `t` > and reused for each value of `x`. The intermediate

Re: Repeated computations under a lambda

2017-07-18 Thread Conal Elliott
Here's the code in question, slightly rephrased: > exampleC t = \ x -> x + s where s = sin t I wrote it this way so that `sin t` would be computed once per `t` and reused for each value of `x`. The intermediate result `s` has type `Double`---not a function. Without

Re: Repeated computations under a lambda

2017-07-18 Thread David Feuer
On Tuesday, July 18, 2017 3:55:28 PM EDT Conal Elliott wrote: > Hi Sebastian, > > Thanks for the reply. It's that I don't want `exampleC` to be eta-expanded. > Apparently GHC does by default even when doing so moves computation under > lambda. I've thought otherwise for a very long time. GHC

Re: Repeated computations under a lambda

2017-07-18 Thread Conal Elliott
Hi Sebastian, Thanks for the reply. It's that I don't want `exampleC` to be eta-expanded. Apparently GHC does by default even when doing so moves computation under lambda. I've thought otherwise for a very long time. -- Conal On Tue, Jul 18, 2017 at 9:48 AM, Sebastian Graf

Re: Repeated computations under a lambda

2017-07-18 Thread Conal Elliott
> the exampleC is the bound things that is eta-expanded. Oh! I get it now. Thanks. > The problem is that GHC’s optimizer uses a cost-model [...] that does not hold in your case. Makes sense a well. I'll use `-fno-do-lambda-eta-expansion` for now and see well it works. Thanks very much for

Re: Repeated computations under a lambda

2017-07-18 Thread Joachim Breitner
Hi Conal, Am Dienstag, den 18.07.2017, 15:35 -0700 schrieb Conal Elliott: > Thanks very much for this reply, Joachim. I see that `-fno-do-lambda- > eta-expansion` with my example prevents moving the computation under > the lambda where it gets repeatedly evaluated. I don't understand > what this

Re: Repeated computations under a lambda

2017-07-18 Thread Conal Elliott
Thanks very much for this reply, Joachim. I see that `-fno-do-lambda-eta-expansion` with my example prevents moving the computation under the lambda where it gets repeatedly evaluated. I don't understand what this code motion/substitution has to do with eta-expansion. Is it that the `let`

RE: Proposed: Language.Haskell.TH.Internal

2017-07-18 Thread Simon Peyton Jones via ghc-devs
OK with me, provided we document the thinking so that users understand the architecture. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Richard | Eisenberg | Sent: 18 July 2017 13:27 | To: GHC developers | Cc: Ryan

Re: Repeated computations under a lambda

2017-07-18 Thread Joachim Breitner
Hi, Am Dienstag, den 18.07.2017, 08:34 -0700 schrieb Conal Elliott: > I'm seeing what looks like repeated computation under a lambda with > `-O` and `-O2`. The following definition: > > > exampleC :: Double -> Double -> Double > > exampleC = \ t -> let s = sin t in \ x -> x + s > > yields this

Re: Repeated computations under a lambda

2017-07-18 Thread Sebastian Graf
Hi Conal, so if I understand this right, you'd rather not wanted `exampleC` to be eta-expanded (or the binding of `s` to be floated into the lambda)? Or is it that you want CSE to find out that you always supply the same `t` as the first argument and share the partial application and thus the

Re: Proposed: Language.Haskell.TH.Internal

2017-07-18 Thread Alan & Kim Zimmerman
This can serve as a starting point for the Trees that Grow implementation too, I understand Shayan Najd is intending to eventually harmonise the hsSyn AST and the TH one. Alan On 18 July 2017 at 14:27, Richard Eisenberg wrote: > Hi devs, > > This is a brief proposal for

Proposed: Language.Haskell.TH.Internal

2017-07-18 Thread Richard Eisenberg
Hi devs, This is a brief proposal for an internal, non-user-facing restructuring of the implementation of Template Haskell. It's here (instead of at ghc-proposals) because it's not user-facing. When a user writes a TH quote [| foo bar baz |], GHC must desugar that into some Core code that