Dear Ian, et al.
On 17 May 2012, at 16:41, Ian Lynagh wrote:
> For what it's worth, I recently looked at doing this, but all the
> options seemed to end up very ugly.
>
> The most promising approach was using something like this:
>
> data None = None
>
> type family PostTc i t :: *
> type instance PostTc RdrName a = None
> type instance PostTc Name a = None
> type instance PostTc Id a = a
>
> ---
>
> data ForeignDecl name =
> ...
> | ForeignExport (Located name)
> (LHsType name)
> (PostTc name Coercion)
>
> but then you get GHC needing a "Data (PostTc id Coercion)" instance all
> over the place, which would result in a lot of noise.
>
> This could potentially be fixed by using DataKinds to close the set of
> types that PostTc can return, but that isn't currently possible (see
> http://hackage.haskell.org/trac/ghc/ticket/6074#comment:5
> ), and even if it was, it would be a few years before we could use it in
> GHC.
This had occurred to me and also had me looking at the closing of kinds.
However, since it will be a while before we can use closed kinds in the
compiler itself, I figured a slightly uglier, but practical solution would be
to end up with:
data HsType typ name =
…
| HsExplicitListTy typ (LHsType typ name)
…
which has me spreading that 'typ' variable all through the AST. Hence the
attempt to automate the refactoring.
The upside of this method, is that we can simply introduce
class Typed x t where
extractType :: x -> t
which should solve quite a few different GHC API requests for type extraction.
>> The build system resolves the directories in the GHC source tree, so I'm
>> compensating for this by seeing which files I can find. To this end, I first
>> build a name table by seeing what files I can find in the source tree:
>
> I'm a little confused. Why aren't you just setting importPaths (like the
> ghc -ifoo flag does)?
Ah, ignorance, mostly. It was the same ignorance that had lead me to think I
actually needed to load all these modules. Instead, I now just use the purely
functional parser (which led me to wonder; why is there only a purely
functional parser? Why not a type checker, etc.?)
In short, I've solved my problem now by just using the purely functional
parser. I hope I can come with a patch for review relatively soon. Thanks for
your comments, though.
Regards,
Philip
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
