Typechecker plugins: request for review and another workflow question

[Adam Gundry]

I've just pushed wip/tc-plugins-amg, in which I remove the hs-boot file
and unify the core2core and typechecker plugins under a single -fplugin
flag. This did involve making a separate module for plugins, which I
think is probably a good thing.

I looked at using a hook instead, with a plugin to modify hooks, but I'm
not sure exactly where such a plugin should be invoked. Ideally we want
the typechecker modifications to work on a per-module basis, but most of
the hooks seem to have a wider scope than that.

Adam


On 11/11/14 03:08, Eric Seidel wrote:
> 
>> On Nov 10, 2014, at 07:58, Austin Seipp <austin at well-typed.com> wrote:
>>
>> Hi Iavor;
>>
>> I took a very, very cursory glance. Naturally I am not a typechecker
>> guru, but I did look over the mechanical changes/extensions to thread
>> things around. Two things popped out to me:
>>
>> - 1) Ugh, a new .hs-boot file. I assume this wasn't added without
>> good reason, but ideally we would be eliminating them quicker than we
>> add them. :) I want to take a closer look at this; perhaps we can
>> refactor something for you to remove the need for this.
>>
>> - 2) I am kind of not a fan of having separate 'plugins for
>> core2core' and 'plugins for typechecking' flags, AKA -ftc-plugin and
>> -fplugin. Ideally I would think all plugins could be uniformly
>> specified by simply saying '-fplugin'. This mostly avoids the need for
>> duplication and a naming convention/slew of flags for each case (which
>> we have to catalog and document). There may be an easy way to make
>> this the case; I haven't looked closely yet (it has been some time
>> since I starred at the plugin code, even though Max wrote it and I
>> helped get it merged!)
> 
> I looked into this again a bit today and recall now why we made a separate
> Plugin type and flag; adding the TcPlugin to the existing Plugin type defined
> in CoreMonad creates a circular dependency between CoreMonad and TcRnTypes.
> 
> We could (and perhaps should) move all of the plugin types into a separate
> module, but that would require pulling other types (e.g. CoreToDo) out of
> CoreMonad to break the circularity.



-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/