2013/8/26 Ben Lippmeier b...@ouroborus.net
On 23/08/2013, at 3:52 AM, Ryan Newton wrote:
Well, what's the long term plan? Is the LLVM backend going to become
the only backend at some point?
I wouldn't argue against ditching the NCG entirely. It's hard to justify
fixing NCG performance
Well, what's the long term plan? Is the LLVM backend going to become the
only backend at some point?
I wouldn't argue against ditching the NCG entirely. It's hard to justify
fixing NCG performance problems when fixing them won't make the NCG faster
than LLVM, and everyone uses LLVM
Previously the tagToEnum# was optimised away in the code generator in
the common cases. Perhaps the Simplifier will do that for the wrappers
now, I don't know.
This special case is still in the code generator and it will be there until we
move handling of
tagToEnum# to Core. So using
On Sun, Aug 25, 2013 at 9:47 PM, Simon Marlow marlo...@gmail.com wrote:
On 25/08/13 20:16, Jan Stolarek wrote:
We really want people to use the new primops, not the wrappers
We do? Could you justify why we want to people to use primops?
What I meant was, if people are already using
On 26/08/13 09:50, Jan Stolarek wrote:
I don't mind breaking these very low-level APIs.
We are breaking that API at the moment, except that you propose to break it by
chnaging type
signatures, whereas I chose to break it by changing names. So currently the
change in primops
will not go
So since we have to break the API anyway, why not break it in the way
that we want?
Oh, but the thing is we don't! We have a plan to rename GHC.Prim to
GHC.Prim.BuiltIn, rename
GHC.PrimWrappers (in ghc-prim) to GHC.Prim and make it re-export
GHC.Prim.BuiltIn [1]. This way
change will be
On 26/08/13 10:38, Jan Stolarek wrote:
So since we have to break the API anyway, why not break it in the way
that we want?
Oh, but the thing is we don't! We have a plan to rename GHC.Prim to
GHC.Prim.BuiltIn, rename
GHC.PrimWrappers (in ghc-prim) to GHC.Prim and make it re-export
I guess that's a valid argument. I'll discuss this with Simon tomorrow.
Janek
Dnia poniedziałek, 26 sierpnia 2013, Simon Marlow napisał:
On 26/08/13 10:38, Jan Stolarek wrote:
So since we have to break the API anyway, why not break it in the way
that we want?
Oh, but the thing is we
Hey everyone,
I'm having trouble finding a good middle ground between the global and
local environments in the typechecker. I would like to get an
environment of things that are defined in the current module, but
- TcGblEnv includes everything in scope, which is too general.
- TcLclEnv is (if
I believe that maybe the fact that HP installer didn’t add the directory to my
path is spurious:
·I unpacked the files to the wrong directory; then moved them. Of
course that put the PATHs out of date
·HP installer changed my *system* settings not *user* settings, so I
didn’t
Hello. I'm Yoshikuni Jujo.
I want to correct ppr_dec of Language.Haskell.TH.Ppr.
Now:
ppr $ FunD (mkName $$) [Clause [] (NormalB $ VarE $ mkName x) []]
= $$ = x
but I want:
ppr $ FunD (mkName $$) [Clause [] (NormalB $ VarE $ mkName x) []]
= ($$) = x
I'll send patch.
--
11 matches
Mail list logo
