On 12/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
The current situation is that ExternalCore.lhs defines datatypes for
both expressions and types (Exp and Ty, respectively), and the
External Core parser uses IfaceType to represent type declarations,
and IfaceBndr to represent term declarations.
A while back, Simon PJ suggested extending HsBind with an alternative
for External Core bindings, and using that instead of IfaceBndr for
term declarations. Unfortunately, the parser sometimes needs to parse
types that appear as components of terms (such as abstractions, and
case expressions), and sometimes needs to parse them as part of type
declarations. Thus, the parser either needs separate productions for
parsing types that appear in terms and in type declarations, or code
to convert between IfaceType and Ty.
One way to simplify this situation would be to remove the Ty data
type altogether, and use IfaceType in ExternalCore. Code already
exists to parse External Core into an IfaceType representation, and
pretty-printing IfaceTypes shouldn't be any harder than pretty-
printing Tys. However, doing this would require ExternalCore, which
currently imports nothing at all, to import IfaceType. IfaceType, in
turn, imports a number of other modules. So ExternalCore would no
longer be so appealingly self-contained.
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.
Cheers,
Kirsten
--
Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt
"What doesn't kill you, makes you stronger -- or puts you on a talk show."
--Carrie Fisher
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
