On 6/29/07, Simon Marlow <[EMAIL PROTECTED]> wrote:
Ok, I'm not sure that the layering is quite right here - it doesn't seem right
for compileToCore to set the targets. compileToCore should really be a
higher-level API, built in terms of the GHC API.
Still, I don't suggest changing it until we'
Tim Chevalier wrote:
On 6/28/07, Simon Marlow <[EMAIL PROTECTED]> wrote:
The right sequence would be
(a) setTarget to the desired filename
(b) depanal
(c) find the module name by searching in the ModGraph
(d) checkModule
and checkModule should optionally return the Core too.
Unfortuna
02:53
| To: Simon Marlow
| Cc: cvs-ghc@haskell.org
| Subject: Re: External Core in binary format
|
| On 6/28/07, Simon Marlow <[EMAIL PROTECTED]> wrote:
| > The right sequence would be
| >
| > (a) setTarget to the desired filename
| > (b) depanal
| > (c) find the module
On 6/28/07, Simon Marlow <[EMAIL PROTECTED]> wrote:
The right sequence would be
(a) setTarget to the desired filename
(b) depanal
(c) find the module name by searching in the ModGraph
(d) checkModule
and checkModule should optionally return the Core too.
Unfortunately, checkModule curr
Tim Chevalier wrote:
On 6/27/07, Neil Mitchell <[EMAIL PROTECTED]> wrote:
It works fine. The problem is that loadCoreFile takes a filename, and
the module name of that filename. Is there any way I can modify this
code to not require the module name, but get it from the API?
Yeah, I figured t
On 6/27/07, Neil Mitchell <[EMAIL PROTECTED]> wrote:
It works fine. The problem is that loadCoreFile takes a filename, and
the module name of that filename. Is there any way I can modify this
code to not require the module name, but get it from the API?
Yeah, I figured that might be a source
Hi Tim (and all other GHC API gurus)
I managed to get most of the way towards where I was aiming for.
Ideally I want an interface such that loading a filename gives me the
GHC Core out of it.
Here is what I have so far (strongly stolen from Tim):
import GHC
import Outputable
import CoreSyn
ghc
On 6/25/07, Neil Mitchell <[EMAIL PROTECTED]> wrote:
Hi Tim
> Mon Jun 25 15:06:08 PDT 2007 Tim Chevalier <[EMAIL PROTECTED]>
> * Add a compileToCore function to the GHC API
Yay! Thanks very much. I've never used a nightly snapshot of GHC
before, but if I grab one tomorrow will it have this a
Hi Tim
Mon Jun 25 15:06:08 PDT 2007 Tim Chevalier <[EMAIL PROTECTED]>
* Add a compileToCore function to the GHC API
Yay! Thanks very much. I've never used a nightly snapshot of GHC
before, but if I grab one tomorrow will it have this ability in it?
So it's not quite as simple as just call
I've checked in code for the function Neil asked for:
Mon Jun 25 15:06:08 PDT 2007 Tim Chevalier <[EMAIL PROTECTED]>
* Add a compileToCore function to the GHC API
Here is the program I used for testing it:
-
import GHC
import DynFlags
import PackageConfig
import BasicTypes
import Outpu
We can definitely add those to the existing data types, but it
wouldn't be entirely trivial. I believe some of them already have
Read and Show instances which don't do quite what we want, and
changing them to automatically-derived instances might make other
bits of the compiler behave dif
Hi
Well, in GHC the Prelude ~= the base package, so you'll have to translate (a
large chunk of) base into YHC.Core. It uses lots of primitives, so you'll need
translations for many of those (exceptions? MVars? GMP operations?).
Trivial :)
Yhc.Core has the notion of primitives, which is som
Neil Mitchell wrote:
So presumably you'd be happy if you could do something like this:
import qualified GHC
getYHCCore :: FilePath -> YHC.Core
getYHCCore file = do
s <- GHC.newSession
ghc_core <- GHC.compileToCore s "Foo.hs"
convertToYHCCore ghc_core
ie. without any on-disk rep
Hi
So presumably you'd be happy if you could do something like this:
import qualified GHC
getYHCCore :: FilePath -> YHC.Core
getYHCCore file = do
s <- GHC.newSession
ghc_core <- GHC.compileToCore s "Foo.hs"
convertToYHCCore ghc_core
ie. without any on-disk representation at all
Neil Mitchell wrote:
I guess I started this discussion by asking for a concrete thing,
rather than describing what I'm hoping to do. In reality, any solution
that accomplishes my end goal suits me perfectly - so perhaps I should
say what I'm hoping to do.
Currently Yhc has an external core forma
Hi
I guess I started this discussion by asking for a concrete thing,
rather than describing what I'm hoping to do. In reality, any solution
that accomplishes my end goal suits me perfectly - so perhaps I should
say what I'm hoping to do.
Currently Yhc has an external core format, Yhc.Core. Howev
On 6/17/07, Stefan O'Rear <[EMAIL PROTECTED]> wrote:
On Sun, Jun 17, 2007 at 12:08:26PM -0700, Tim Chevalier wrote:
> There's nothing to stop us from just adding deriving(Show) and
> deriving(Read) to those existing data types, right? Of course, this
> requires adding instances for a number of da
On Sun, Jun 17, 2007 at 12:08:26PM -0700, Tim Chevalier wrote:
> On 6/16/07, Aaron Tomb <[EMAIL PROTECTED]> wrote:
> >We've been leaning away from having a specific data type for External
> >Core, and just using the existing data types in GHC (such as
> >IfaceExpr and CoreExpr). So it's unclear wha
On 6/16/07, Aaron Tomb <[EMAIL PROTECTED]> wrote:
We've been leaning away from having a specific data type for External
Core, and just using the existing data types in GHC (such as
IfaceExpr and CoreExpr). So it's unclear what data type we'd add
deriving(Show) to.
There's nothing to stop us fro
| To: [EMAIL PROTECTED]
| Cc: Simon Marlow; cvs-ghc@haskell.org; Matthew Naylor
| Subject: Re: External Core in binary format
|
| Hi
|
| > I'm not sure
| > offhand why just doing Read/Show wouldn't work or didn't occur
to us;
| > is there a reason why that wouldn't
EMAIL PROTECTED]
| Cc: Simon Marlow; cvs-ghc@haskell.org; Matthew Naylor
| Subject: Re: External Core in binary format
|
| Hi
|
| > I'm not sure
| > offhand why just doing Read/Show wouldn't work or didn't occur to us;
| > is there a reason why that wouldn't be straightfor
Hi
I'm not sure
offhand why just doing Read/Show wouldn't work or didn't occur to us;
is there a reason why that wouldn't be straightforward?
Talking to Matt, the only thing is that currently Show is used for the
pretty printed version. Adding a new Ppr class and using that
shouldn't be that h
On 6/13/07, Neil Mitchell <[EMAIL PROTECTED]> wrote:
I know time is a bit variable, but is there any idea of when this
might be accomplished? Is there anything fundamental that is holding
you back? Something like writing Read/Show serialisation would take a
day at most, and give me everything I w
Hi Tim
Not if you want to parse Core emitted by the HEAD, since in the process
of trying to get Core working, Aaron and I had to change the data types to
reflect type system changes. We hope to have something checked in within a
finite amount of time :-)
I know time is a bit variable, but is t
On 6/13/07, Neil Mitchell <[EMAIL PROTECTED]> wrote:
> Isn't there a canonical parser and data types for GHC's core somewhere?
Is there? I've asked if such a thing exists several times, and each
time I get told it doesn't. If there was that would make me very happy
:)
Not if you want to pars
Hi
> Matt has kindly volunteered to implement this, if you would be happy
> to accept such a patch.
In principle yes, but I see some practical problems.
Which binary library? There's one in GHC already, but if you wanted your parser
to be compatible, you'd have to use the same library (or car
On Wed, Jun 13, 2007 at 01:44:10PM +0100, Neil Mitchell wrote:
> Hi,
>
> I was wondering if you would be happy with the addition of a flag to
> generate Haskell Core (.hcr) files in a binary format, in addition to
> the text format currently generated? This would allow for easy parsing
> of the re
Neil Mitchell wrote:
I was wondering if you would be happy with the addition of a flag to
generate Haskell Core (.hcr) files in a binary format, in addition to
the text format currently generated? This would allow for easy parsing
of the resultant files, something which is currently not possible
Hi,
I was wondering if you would be happy with the addition of a flag to
generate Haskell Core (.hcr) files in a binary format, in addition to
the text format currently generated? This would allow for easy parsing
of the resultant files, something which is currently not possible.
Matt has kindly
29 matches
Mail list logo
