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 Wed Jul 16 18:02:06 BST 2008.
checking out
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 Wed Jul 16 18:12:06 BST 2008.
checki
| I think this feature has shaped up pretty nicely after the helpful
| suggestions I recieved. I don't know if I'll be able to get the patch
| into GHC proper, though..
Maybe this comment predates our Trac interaction, but if,
- in the light of the feedback you've had, you think there's something
| 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 people using
| the libraries in
Hi
> Might help if library author and user are related?-)
Yes :-) I'd like to think that anyone can use Uniplate in a very
high-level manner, but someone other than me needs to argue that.
> So far, I still think that SYB for GHC types is a good and necessary
> first step. If adding Uniplate
I find Uniplate to be completely the opposite. I always use the
predefine schemes, and they are nearly always exactly what I want.
Whether this is a difference in the traversals provided by the
library, or in the mindset of the user of the library is still up for
debate.
Might help if library au
Hi
> > too general to allow the Uniplate solution, but it would be easy to
> > add universe/transform to SYB and implement them using them much more
> > efficiently.
> >
>
> It has been a while, and most of my experience was with Strafunski's
> StrategyLib, but I seem to recall using the predefin
in SYB were (a) traversing irrelevant parts of the structure
(because everything is treated generically)
Yes, this is a big one. In particular Haskell String's being defined
as [Char] makes SYB do a lot of redundant work on characters which are
unlikely to be the target. SYB's types for everyt
Hi
> > No boilerplate removal code 1:30min
> > Uniplate with PlateDirect (fastest method) 1:45min
> > Uniplate with PlateData (based on SYB) 5min
> >
> > And I suspect directly using SYB would have been somewhere in the
> > 10-15min range.
> >
>
> It would be useful to have more information about
Hi Ian,
Since, meanwhile, my particular problem is solved, this is meant just as
additional information for others to work around similar problems.
Ian Lynagh wrote:
> On Tue, Jul 15, 2008 at 04:50:44PM +0200, Jost Berthold wrote:
>>
>> For some complicated-to-explain reason, I do not have it (bu
Hi
> How did you define the Data instances for the abstract types
> (break the abstraction or define the instances abstractly), and how do your
> instances compare to the ones at
> http://hackage.haskell.org/trac/ghc/wiki/GhcApiAstTraversals
> ?
The Uniplate one's can't transform the type, and
> How did you define the Data instances for the abstract types
> (break the abstraction or define the instances abstractly), and how do your
> instances compare to the ones at
> http://hackage.haskell.org/trac/ghc/wiki/GhcApiAstTraversals ?
The instances do not attempt to traverse the abstract dat
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 people using
the libraries in practice
On Tue, Jul 15, 2008 at 04:50:44PM +0200, Jost Berthold wrote:
>
> For some complicated-to-explain reason, I do not have it (but I do have
> one called "ghc-6.8.3" in the path). As you can see, I configured the
> build to use ghc-6.8.3 as the haskell compiler. However, it calls "ghc"
> here. Unsur
I don't know enough about Uniplate to make a judgement on that point,
so I'll just pipe up and say that having Data/Typeable instances for
Expr, Binds and friends would be of much benefit to the GHC plugins
project. I've actually already written my own instances and put them
straight into CoreSyn.
I've never found the rationale for GHC's binary incompatibility
very convincing (yes, we want cross-package optimizations, and
yes, we do like it if GHC V(n+1) does a better job at compiling
package P than GHC Vn did; but why can't GHC V(n+1) do
at least as good a job as GHC Vn with package P comp
Hi
> You can implement Uniplate on top of Data/Typeable. (It's slightly slower
> than giving Uniplate instances directly, but if my memory serves, not a lot.
> See Neil's theis.) So you can think of Uniplate/Biplate as a rather nice API
> for generic programming, but one that shares a common
| > Neil Mitchell tells me that he and Simon PJ are in favour of adding
| > instances for Data, Typeable, and Uniplate for many of the datatypes used
| > inside GHC. I agree that this should certainly be done for the external
| > interface of GHC, i.e., core-plugins and GHC API. Here they could
Build results:
gabor stable: pass
kgardas stable: fail (failed stage1)
mnemosyne x86-64 Gentoo stable: pass
x86 Windows stable: lost
x86 Windows stable fast:lost pass lost
x86-64 Linux stable:lost
Old unexpected test passes:
T1
Build results:
x86-64 Linux head: lost
x86 Windows head:lost
x86 Windows head fast: lost pass lost
tnaur PPC OSX head 2:pass
tnaur x86 Linux head:pass
x86-64 Linux head unreg: lost
New unexpected test failures:
conc024 1 tnaur x86 Linux head
conc032 1 tnaur x86
20 matches
Mail list logo
