| Am Sonntag, 23. Dezember 2007 13:35 schrieb Isaac Dupree:
| > GHC optimizes less effectively when parts of a program are in different
| > modules, or are exported from a module.
|
| By the way, does GHC do cross-package optimization (not just cross-module
| optimization within packages)?
GHC doe
g9ks157k:
> Am Sonntag, 23. Dezember 2007 13:35 schrieb Isaac Dupree:
> > GHC optimizes less effectively when parts of a program are in different
> > modules, or are exported from a module.
>
> By the way, does GHC do cross-package optimization (not just cross-module
> optimization within package
On Thu, Dec 27, 2007 at 01:47:44PM +0100, Wolfgang Jeltsch wrote:
> Am Sonntag, 23. Dezember 2007 13:35 schrieb Isaac Dupree:
> > GHC optimizes less effectively when parts of a program are in different
> > modules, or are exported from a module.
>
> By the way, does GHC do cross-package optimizati
Am Sonntag, 23. Dezember 2007 13:35 schrieb Isaac Dupree:
> GHC optimizes less effectively when parts of a program are in different
> modules, or are exported from a module.
By the way, does GHC do cross-package optimization (not just cross-module
optimization within packages)?
> […]
Best wishe
On 12/24/07, Isaac Dupree <[EMAIL PROTECTED]> wrote:
> Stefan O'Rear wrote:
> > It's been done. http://www.cs.utah.edu/~hal/HAllInOne/index.html
> >
> > Stefan
>
> which alas seems to have a ridiculous, probably unenforcable license :-)
> Interesting though - I wonder how correct it is.
>
[wildly
Stefan O'Rear wrote:
It's been done. http://www.cs.utah.edu/~hal/HAllInOne/index.html
Stefan
which alas seems to have a ridiculous, probably unenforcable license :-)
Interesting though - I wonder how correct it is.
"
This code is licensed under the Big-Kazooba-Ritual license:
You may copy
On 12/24/07, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> The GHC API ought to make this relatively easy, but sadly doesn't at the
> moment. What you'd want:
>
> - read in each module in turn, typecheck, desugar, perform modest
> simplification, and keep the resulting Core bindings
The API c
Simon Peyton-Jones wrote:
Of course one group would be best, but you might run out of memory...
I wonder what the memory-complexity (and time-complexity) of
GHC-with-optimizations is. (I suppose this could be found out by testing)
Isaac
___
Glasgow
y others should just work better when you can see more of the program at
once.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:glasgow-haskell-
| [EMAIL PROTECTED] On Behalf Of Neil Mitchell
| Sent: 23 December 2007 12:48
| To: Isaac Dupree
| Cc: GHC Users
| Subjec
On 12/23/07, Neil Mitchell <[EMAIL PROTECTED]> wrote:
> Neil - who really wants external Core
>
I hate to advertise anything prematurely, but I'm hopefully going to
be devoting some serious time to this starting very soon. (I guess
that stating it here will put more pressure on me to finish it :-)
On Sun, Dec 23, 2007 at 07:35:20AM -0500, Isaac Dupree wrote:
> GHC optimizes less effectively when parts of a program are in different
> modules, or are exported from a module. Therefore, merging all the code
> into one "module Main (main)" would help. Unfortunately, Haskell source
> syntax i
Hi Isaac,
I've had similar thoughts before. Once GHC can read and write external
Core this should become a half hour hack. I did a similar thing in
Yhc, and it really is trivial
(http://darcs.haskell.org/yhc/src/compiler98/Core/Linker.hs). I'm sure
there would be a few corner cases, but those kind
GHC optimizes less effectively when parts of a program are in different
modules, or are exported from a module. Therefore, merging all the code
into one "module Main (main)" would help. Unfortunately, Haskell source
syntax is ill-suited to this; for example:
module-boundary monomorphism rest
13 matches
Mail list logo
