Dear all,
I'm working with Alan to instantiate everything for Data.Data, so that we can
do better SYB-traversals (which should also help newcomers significantly to get
into the GHC code base). Alan's looking at the AST types, I'm looking at the
basic types in the compiler.
Right now, I'm
The definition dates back to 1996, so it seems plausible that
newtype is the way to go now.
Edward
Excerpts from p.k.f.holzenspies's message of 2014-08-15 11:52:47 +0100:
Dear all,
I'm working with Alan to instantiate everything for Data.Data, so that we can
do better SYB-traversals
Eek. Glancing at this I see that every single data type has an extra type
parameter. To me this feels like a sledgehammer to crack a nut. What is wrong
with the type-function approach?
Simon
From: Alan Kim Zimmerman [mailto:alan.z...@gmail.com]
Sent: 13 August 2014 07:50
To: Philip K.F.
Simon,
I've been encouraging the type family approach. See
https://phabricator.haskell.org/D157
Thanks,
Richard
On Aug 15, 2014, at 11:17 AM, Simon Peyton Jones simo...@microsoft.com wrote:
Eek. Glancing at this I see that every single data type has an extra type
parameter. To me this
Great. Please can what you do be documented clearly somewhere, with a link to
that documentation from here
https://ghc.haskell.org/trac/ghc/wiki/Repositories, and/or somewhere else
suitable?
Thanks
Simon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On
Did you look at https://phabricator.haskell.org/D157? It superseded
https://phabricator.haskell.org/D153
On Fri, Aug 15, 2014 at 5:17 PM, Simon Peyton Jones simo...@microsoft.com
wrote:
Eek. Glancing at this I see that every single data type has an extra
type parameter. To me this feels
I'm having trouble when it doesn't fuse—it ends up with duplicate bindings
at the top level, because build gets inlined n times, and the result lifted
out. Nothing's *wrong* with the code, except that there are multiple copies
of it.
On Aug 15, 2014 10:58 AM, GHC ghc-devs@haskell.org wrote:
Ah, I see. Is there some way for D153 to be retired, then, to avoid
inattentive people looking at it? (I’m wading through a week’s worth of email
backlog.)
I’ll look at D157
S
From: Alan Kim Zimmerman [mailto:alan.z...@gmail.com]
Sent: 15 August 2014 16:36
To: Simon Peyton Jones
Cc:
Isn't this kind of thing fixed for other functions by rewriting back into
the direct recursive definition if no fusion happens?
On Fri, Aug 15, 2014 at 11:41 AM, David Feuer david.fe...@gmail.com wrote:
I'm having trouble when it doesn't fuse—it ends up with duplicate bindings
at the top
Yes, but I'm not sure how to do that, especially because foldl doesn't have
the phased NOINLINE that foldr does.
On Aug 15, 2014 12:45 PM, Dan Doel dan.d...@gmail.com wrote:
Isn't this kind of thing fixed for other functions by rewriting back into
the direct recursive definition if no fusion
Make foldl's inline phased, and see what happens?
Presumably the reason it doesn't have a phase limit yet is that it never
participated in any fusion before, so there was never a reason to not just
inline.
Other than that it seems like:
reverse xs
= rewrite
build (\c n - foldl
11 matches
Mail list logo
