You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We want to measure the impact of partial type constructors on GHC (and, if possible, packages from Hackage). The thought is to get data something like this:
Package
Module
declarations modified (w/ Total)
declarations modified (w/ WFT or @)
Cabal
Foobar
schifty Schfive
Elevenzies
....
...
.........
...........
My idea, at least, to motivate this, is that we have separate sections in the paper on challenges in implementation -- i.e, why we need the Total constraint synonym, or why we need the WFT workaround. Tabulating modifications made to packages by these categories of fixes will allow us to state their impact clearly.
Considerations
If we simply want to count the types we see Total, WFT, or @ added to a declaration, we could just grep. However it would be better to not double dip. Take for example this gem from compiler/Hs/Expr.hs:
This should increment the declarations x modified w/ WFT just once in:
Package
Module
declarations modified (w/ Total)
declarations modified (w/ WFT or @)
Ghc
Ghc.Hs.Expr
...
x + 1
Do note that, I think if we see something like:
foobar:: (Totalf, f@a, WFTG) ::...
that this should increment both the Total field and the WFT / @ field.
Implementation (the less knuckle-headed approach)
I'll want to modify some monad to retain (possibly multiple) Name -> Int maps. Then, when type checking term signatures, instance declarations, or class declarations (these are principally the areas where we must add constraint annotations), I can increment each Name when we see Total, @, or WFT in these signatures' constraints. @ is a wiredin type constructor, so that one should be easy to look for -- I am not sure about Total and WFT. Some care will also need to be placed on doing this before elaboration.
After typechecking, I can dump out this data in the tc trace -- or, make a new dump file. Ideally, I can dump a separate file per module/file into either the _build directory location of that file, or, the module's original location. We can do post-processing thereafter.
Implementation (Leeroy Jenkins)
Just print out a line in the tc trace with all the data you need every time you see the reserved keywords, then aggregate using grep hackery.
Implementation (Edit)
yeah just grep
The text was updated successfully, but these errors were encountered:
Motivation
We want to measure the impact of partial type constructors on GHC (and, if possible, packages from Hackage). The thought is to get data something like this:
Total
)WFT
or@
)My idea, at least, to motivate this, is that we have separate sections in the paper on challenges in implementation -- i.e, why we need the
Total
constraint synonym, or why we need theWFT
workaround. Tabulating modifications made to packages by these categories of fixes will allow us to state their impact clearly.Considerations
If we simply want to count the types we see
Total
,WFT
, or@
added to a declaration, we could just grep. However it would be better to not double dip. Take for example this gem fromcompiler/Hs/Expr.hs
:This should increment the declarations
x
modified w/WFT
just once in:Total
)WFT
or@
)Do note that, I think if we see something like:
that this should increment both the
Total
field and theWFT / @
field.Implementation (the less knuckle-headed approach)
I'll want to modify some monad to retain (possibly multiple)
Name -> Int
maps. Then, when type checking term signatures, instance declarations, or class declarations (these are principally the areas where we must add constraint annotations), I can increment eachName
when we seeTotal
,@
, orWFT
in these signatures' constraints.@
is a wiredin type constructor, so that one should be easy to look for -- I am not sure aboutTotal
andWFT
. Some care will also need to be placed on doing this before elaboration.After typechecking, I can dump out this data in the tc trace -- or, make a new dump file. Ideally, I can dump a separate file per module/file into either the
_build
directory location of that file, or, the module's original location. We can do post-processing thereafter.Implementation (Leeroy Jenkins)
Just print out a line in the tc trace with all the data you need every time you see the reserved keywords, then aggregate using grep hackery.
Implementation (Edit)
yeah just grep
The text was updated successfully, but these errors were encountered: