| So far, I still think that SYB for GHC types is a good and necessary
| first step. If adding Uniplate instances as well gives significant
| improvements in efficiency or convenience, I won't argue against.
An alternative viewpoint might be: do the simpler, more efficient,
and easier-to-use thi
| 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 interfaces, to get all that
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 Thu Jul 17 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 Thu Jul 17 18:12:06 BST 2008.
checki
| So far, I still think that SYB for GHC types is a good and necessary
| first step. If adding Uniplate instances as well gives significant
| improvements in efficiency or convenience, I won't argue against.
An alternative viewpoint might be: do the simpler, more efficient, and
easier-to-use thi
| 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 interfaces, to get all that
I'm not so sure an automatic translation/simplification of the AST
would be so useful for some tools. For example, say
Wait, how did refactorings get into this?-) The simplifications in
this case are more like eliding details from the AST types, to
represent the same source with different, s
(skipping redundant types) its fairly complex but doesn't touch gfoldl,
and most of the difficult code can be stolen from Uniplate.
From your thesis/paper, it seems that queries, such as 'bill' in the
Paradise benchmark, are the worst offenders, performancewise,
and applying your techniques fo
I'm not so sure an automatic translation/simplification of the AST
would be so useful for some tools. For example, say
f x y | Just a <- x, Right a' <- y = foo
| Left b <- y= bar
| otherwise = baz
gets translated to
f x y = case x of
However, until this fundamental issue is addressed, is there any
way to make GHC Api clients less dependent on the details of a specific
GHC Api version? In the scenario given above, if T,
despite being built with GHC V1, was able to work with GHC
V2's Api, then it could use GHC V2's formats des
I think you've veered onto a different (but related) topic here. I was
talking about binary compatibility between libraries, you're talking about
allowing the GHC API to make use of .hi files generated by a different
version of GHC.
Right. I was also assuming that, to link with a library, yo
Neil Mitchell wrote:
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.
That was also my sense when I used Uniplate, but I didn't really use it
enough t
Claus Reinke wrote:
However, until this fundamental issue is addressed, is there any
way to make GHC Api clients less dependent on the details of a specific
GHC Api version? In the scenario given above, if T,
despite being built with GHC V1, was able to work with GHC
V2's Api, then it could use
Claus Reinke wrote:
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 V
Build results:
x86-64 Linux head:lost
x86 Windows head: fail (failed stage3 bindist bindisttest failed
slave lost)
x86 Windows head fast:pass pass lost
gabor head: fail (failed darcs)
kgardas head: fail (failed stage1)
mnemosyne x86
Build results:
tnaur PPC OSX stable 2: pass
tnaur x86 Linux stable: pass
x86 Windows stable: lost
x86 Windows stable fast: pass lost pass lost
x86-64 Linux stable: lost
Old unexpected test passes:
T1900 6 gabor stable
T1999 6 gabor stable
Old unexpected test failures:
16 matches
Mail list logo
