Build description = STABLE on i386-unknown-linux
(cam-02-unx.europe.corp.microsoft.com)
Build location= /playpen/simonmar/nightly/STABLE
Build config file = /home/simonmar/nightly/site/msrc/conf-STABLE-cam-02-unx
Nightly build started on cam-02-unx at Fri Jul 18 18:12:05 BST 2008.
checki
Build description = HEAD on i386-unknown-linux
(cam-02-unx.europe.corp.microsoft.com)
Build location= /playpen/simonmar/nightly/HEAD
Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-02-unx
Nightly build started on cam-02-unx at Fri Jul 18 18:02:05 BST 2008.
checking out
I wasn't suggesting changing GHC to *use* generic traversals. Rather, I was
suggesting to initially use the simplest available technology to *provide* the
possibility of generic operations to clients of the GHC API. They can choose
whether or not to use them.
Simon
| -Original Message
IntSets of TypeRepKeys!-)
IntSet's are only possible in 6.8 due to API changes :-)
infinite possibilities of combining type-level programming
with efficient execution!-)
I couldn't quite figure out how to make a type-dependent CAF in the class
instances, as your paper suggests, so I made m
Claus is asking that we use an extensible .hi-file format too, to allow
some GHC API clients to work with libraries compiled by a wider range of
GHC versions. I'm not sure how practical that is, though: what happens
when we introduce new type system extensions, so that the old GHC API can't
un
Hi
> > That approach worries me. We could add generic traversals all over the
> > place, and while none of them is a "bottleneck", the overall effect could
> be
> > quite significant.
>
> I recently added Data and Typeable instance to all AST datatypes
> directly in the code of GHC, the compi
2008/7/18 Simon Marlow <[EMAIL PROTECTED]>:
> That approach worries me. We could add generic traversals all over the
> place, and while none of them is a "bottleneck", the overall effect could be
> quite significant.
>
> The right approach I believe is to keep an eye on compile times when making
>
Simon Peyton-Jones wrote:
| Please reconsider striving for a form of cross-version compatibility
| that will solve this issue for GHC Api clients, as a priority on par with
| binary compatibility.
...
| Perhaps Haskell' should re-consider the idea of having an
| explicit representation of module
Simon Peyton-Jones wrote:
| The thesis suggests that using Uniplate with the fastest instances
| will be around 30% slower than manual operations, but using SYB based
| instances will be 300% slower. In practice, these are benchmarks on
| generic traversals, and may not accurately reflect how peo
On 16/07/2008, at 9:01 PM, Neil Mitchell wrote:
I have also previously talked with Ben Lippmeier about using SYB in
DCC (http://www.haskell.org/haskellwiki/DDC) and was told the
performance loss was "too great" and he had to switch back. However,
these are merely anecdotes.
It was about 3 ti
Hi
> From your thesis/paper, it seems that queries, such as 'bill' in the
> Paradise benchmark, are the worst offenders, performancewise, and applying
> your techniques for Uniplate to the SYB query for 'bill' seems to achieve a
> similar reduction in runtime.
> 'contains' is interesting, and s
Build results:
x86-64 Linux head: lost
x86 Windows head fast: pass pass pass
tnaur PPC OSX head 2:pass
tnaur x86 Linux head:pass
x86-64 Linux head unreg: lost
Fixed unexpected test failures:
conc024
conc032
testblockalloc
Old unexpected test failures:
2047
Build results:
gabor stable: pass
kgardas stable: fail (failed stage1)
mnemosyne x86-64 Gentoo stable: pass
x86 Windows stable fast:pass pass fail (failed configure)
x86-64 Linux stable:lost
Old unexpected test passes:
T1900 6 gabor stab
13 matches
Mail list logo
