Replacing Ty in ExternalCore with IfaceType
atomb at soe.ucsc.edu
Mon Dec 4 14:45:44 EST 2006
It's true that to use External Core in GHC as it stands, you need
IfaceType, and a number of other modules. However, an interesting
aspect of the current External Core is that the ExternalCore module
is only used for _output_. Input goes through IfaceType and
IfaceBndr. So there isn't really an External Core "library". Input
and output are totally distinct. The changes I'm working on replace
IfaceBndr with the Vdefg type from the ExternalCore module.
I think that the original design was the allow a standalone External
Core reference implementation to exist, as one way to describe its
semantics. I believe that, for this tool (which still exists in the
GHC repository) they wanted to share some code with GHC, while not
requiring all of the guts of GHC to be included.
Personally, though, I agree with you. I don't see any reason at this
point to limit the dependencies of the ExternalCore module. It seems
to me that a revised reference implementation could use the GHC as a
library, and still be small and simple enough to serve as a nice
definition of the language.
However, I thought it possible that I might be missing something, and
that there could be other reasons for avoiding dependencies in
ExternalCore, so I asked.
On Dec 4, 2006, at 9:39 AM, Kirsten Chevalier wrote:
> I'm a little confused here. I can understand the desire to minimize
> the amount of code from GHC that External Core requires, but you said
> that the External Core parser uses IfaceType as it is; so, whether or
> not ExternalCore.lhs imports anything from GHC, anyone using the
> External Core library is still going to be using the parser, right? If
> the parser imports IfaceType already, what's the problem with
> ExternalCore importing it too? That seems like the simplest solution
> to me.
> Kirsten Chevalier* chevalier at alum.wellesley.edu *Often in error,
> never in doubt
> "What doesn't kill you, makes you stronger -- or puts you on a talk
> --Carrie Fisher
> Cvs-ghc mailing list
> Cvs-ghc at haskell.org
More information about the Cvs-ghc