Hi Ian, thanks for the info about 7.8. Just to be clear, the new codegen apparently saved my runtimes for the presentation on tuesday. \My\ new code was slower than my old code. The new code generator fixed that, giving me equal running times with much cooler features. I currently assume (without having checked at all) due to dead variable elimination. So if it is getting better, I'd be really really happy. Gruss, Christian * Ian Lynagh [06.09.2012 22:00]:

On Thu, Sep 06, 2012 at 06:32:38PM +0200, Christian Hoener zu Siederdissen wrote:

...

Awesome,

I have been playing with GHC 7.6.0 until today and been very happy. Btw. isn't this the version that officially includes "-fnew-codegen" / HOOPL?

Because the new codegen is optimizing the my ADPfusion library nicely. I lost 50% speed with new features, gained 100% with new codegen, meaning new features come for free ;-)

I suspect that you'll find that the new codegen doesn't work 100% perfectly in 7.6, although I don't know the details - perhaps it just isn't as fast as it could be. It'll be the default in 7.8, though.

Thanks Ian

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Hi Simon, Yes I am using -fnew-codegen. Using a large set of random input data I get the expected results (comparing to both, a different version in Haskell, and one in C). I'll be monitoring output and will report problems. However not relying on it, except to show that high performance is possible. All code I am using for ``production purposes'' uses GHC 7.4 due to library dependencies. Thanks for the note! Christian * Simon Marlow [07.09.2012 09:47]:

On 06/09/2012 21:10, Christian Hoener zu Siederdissen wrote:

...

Hi Ian,

thanks for the info about 7.8. Just to be clear, the new codegen apparently saved my runtimes for the presentation on tuesday. \My\ new code was slower than my old code. The new code generator fixed that, giving me equal running times with much cooler features. I currently assume (without having checked at all) due to dead variable elimination.

So if it is getting better, I'd be really really happy.

Just to be clear - you're using -fnew-codegen, with GHC 7.6.1?

There were a handful of bugfixes to the new codegen path that didn't make it into 7.6.1, so I wouldn't rely on it.

Cheers, Simon

...

Gruss, Christian

* Ian Lynagh [06.09.2012 22:00]:

...

On Thu, Sep 06, 2012 at 06:32:38PM +0200, Christian Hoener zu Siederdissen wrote:

...

Awesome,

I have been playing with GHC 7.6.0 until today and been very happy. Btw. isn't this the version that officially includes "-fnew-codegen" / HOOPL?

Because the new codegen is optimizing the my ADPfusion library nicely. I lost 50% speed with new features, gained 100% with new codegen, meaning new features come for free ;-)

I suspect that you'll find that the new codegen doesn't work 100% perfectly in 7.6, although I don't know the details - perhaps it just isn't as fast as it could be. It'll be the default in 7.8, though.

Thanks Ian

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On Thu, Sep 06, 2012 at 09:42:53AM -0700, Johan Tibell wrote:

2. Could you please push all the packages that were released in GHC 7.6.1 to Hackage as well?

I've now uploaded those that we maintain. Thanks Ian

On Fri, Sep 7, 2012 at 11:05 AM, Herbert Valerio Riedel wrote:

Ian Lynagh writes:

...

On Thu, Sep 06, 2012 at 09:42:53AM -0700, Johan Tibell wrote:

...

2. Could you please push all the packages that were released in GHC 7.6.1 to Hackage as well? I've now uploaded those that we maintain.

...why has bytestring-0.10.0.0 been held back? (afaics, the last couple of versions on Hackage were uploaded by you as well)

Just a reminder that we need that bytestring version on Hackage as other compilers have no way of getting hold of it to fulfill a depedency on bytestring >= 0.10. -- Johan

On Thu, Sep 6, 2012 at 10:33 AM, Felipe Almeida Lessa wrote:

On Thu, Sep 6, 2012 at 1:05 PM, Ian Lynagh wrote:

...

* It is now possible to defer type errors until runtime using the -fdefer-type-errors flag.

I don't remember if this was part of the motivation in creating this feature, but it has a nice use case: asserting on a test suite that something should *not* type check.

We're getting more meta than Haskell provides cleanly, but all significant uses I can currently think of for something like that would require universal quantification over types: Forall types t. t `notElem` someTypes --> fails (tyUnification t MyType) I'm curious what your thinking is here. Thomas

On Thu, Sep 6, 2012 at 2:49 PM, Thomas DuBuisson wrote:

We're getting more meta than Haskell provides cleanly, but all significant uses I can currently think of for something like that would require universal quantification over types:

Forall types t. t `notElem` someTypes --> fails (tyUnification t MyType)

I'm curious what your thinking is here.

I'm developing a EDSL for SQL queries that I'll properly announce tomorrow. The idea I have in mind is that this code should not typecheck: delete $ from $ \table -> set table [] You should not SET something inside a DELETE statement. However, currently that will typecheck---not because I don't know how to fix it, but because the types were already messy enough and I didn't ponder about the tradeoffs. So I would like to put the above snippet on a test suite that says "this should not typecheck". It will serve both as a reminder to fix it someday and as a regression test. Of course, I could stick each of these on a separate file and try to compile it, but that would be a PITA to setup. Is this a crazy idea? =P Cheers, =) -- Felipe.

(Note that ghc-7.4.1 at least does not build [on ARM] with ghc-patched llvm-3.1.)

But ghc-7.4.2 does, for the record.