Generalized phase control for GHC
Max Bolingbroke
batterseapower at hotmail.com
Sat Jul 5 04:12:00 EDT 2008
Hi Roman,
> Three things. Firstly, what would lenient ordering be useful for? You
> probably had a specific use case in mind?
I suspect that when you have multiple plugins all specifying
constraints on the phase ordering independently it is possible to end
up in a situation where using each plugin individually results in a
consistent phase ordering but a combination of multiple plugins causes
a cycle to appear in the order. Hence it is useful to let plugin
authors flag up dependencies they don't >need< to have so we can
intellegently break the cycle using those constraints rather than just
giving up. Admittedly I only have a superstition that this will be a
practical problem.
> Secondly, I think it is quite
> important to be able to specify dependencies for already declared phases.
> That is, I (probably) want to be able to say in module C that phase X from
> module A should come before phase Y from module B.
This in interesting. You're right that it's not possible with this
system: to support this you would need a more class + instance rather
than single declaration flavour for phases. Do you have a practical
example in mind of how you would use it?
> I suspect that's not
> quite possible with your current design. Lastly, in addition to < and > I'd
> also like to have = (i.e., phase X = phase Y which would make X an alias for
> Y).
Ah! This would also let you do what you wanted with your second point:
module C where
{-# PHASE XAlias = A.X, < B.Y #-}
This could indeed be useful, and since it subsumes your other proposal
without complicating the phase declaration experience this looks like
a good extension to have.
> As to the numeric phase ids, I'm all in favour of dropping them altogether.
> For legacy code, you could provide wired-in names 0, 1 and 2 for now but I
> would deprecate them. Also, I'm one of the probably very few people who have
> ever used phase 3 and beyond and dropping support for that is perfectly fine
> with me.
Agreed: we should deprecate numeric ids if we have this alternative.
Thanks for your interesting comments!
Max
More information about the Glasgow-haskell-users
mailing list