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. However, its certainly not a "state dump" of the internals of Yhc's syntax - it dropped some features (FatBar) and added others (Lambda). The intention is that Yhc.Core is a standalone format and library which Yhc currently generates, but that any compiler could potentially generate Yhc.Core, and even if we end up rewriting 50% of Yhc we aren't going to have to change Core. Realistically, GHC is the compiler that can actually compile Haskell programs, so I'd love to "get Yhc.Core" from GHC. This would immediately give the benefit that lots of Haskell source analysis tools (at least 6 so far) would suddenly work with all of GHC's Haskell. I don't mind how we get Yhc.Core out of GHC, but I suspect the cleanest method is for us to transform GHC Core to Yhc.Core. As such, having a GHC Core which was not too tangled with the rest of GHC would be very beneficial. Ideally I want a library "ghc core" which provides an abstract syntax tree for core, and some method to serialise/deserialise to disk. I would then write a library "hs core" which could convert ghc core to yhc core. Thanks Neil On 6/17/07, Tim Chevalier <[EMAIL PROTECTED]> wrote:
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 data types. I guess the real > > problem is that someone such as Neil who wants to read in the > > resulting code would have to import a lot of code from GHC. > > Why is that a problem? It's almost completely automatic: > > import GHC > Maybe it's not a problem. But it seems to me like one of the reasons to bother having an external file format at all is so that people can write tools to process Core without having their code be (too) entangled with GHC. It could be that that's a lost cause, or it could be that since, as you point out, snarfing in code from GHC is a lot easier than it used to be, maybe this is no longer one of the reasons to support an external file format for Core. Cheers, Tim -- Tim Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "Aristotle maintained that women have fewer teeth than men; although he was twice married, it never occurred to him to verify this statement by examining his wives' mouths." -- Bertrand Russell _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
_______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
