On Fri, Mar 14, 2008 at 5:30 PM, Wolfgang Jeltsch
I have a feedback from my Grapefruit co-developer about those aliases in the type-level package. He told me that on his machine, building this package took about 15 minutes, obviously because the machine ran out of RAM. He also told me that the generated object code was very large, and that loading the documentation page generated by Haddock took very long.
Fair point, it akes quite some time in my machine too (not 15minutes though)
And he made a very good point: Who needs aliases for *all* numbers until, say, 10000? Who needs to hard-code the vector length 8247 in his code?
If I remember correctly aliases are generated until decimal 5000, which might me really long anyway.
I think that in practice, you only need very few numbers hard-coded. So it might be better to export a function for letting the package user generate the necessary aliases himself.
I even think that it is probably sensible to drop the alias thing completely, at least if you have vector lengths in mind. What vector lengths will appear as fixed in a real world program? 1000? I think, usually you have only sizes like 2 or 3 hard-coded, for vectors in the mathematical sense. And their representation is already very short: D2, D3, … Remember that computed numbers are not shown as aliases in error messages, only numbers that directly appear in your code.
My co-author also mentioned that he doesn't see much use for octal and hexadecimal notation.
So I propose to drop alias support from type-level or at least let the package user do the necessary generation.
I think that removing aliases completely is not a good idea. How about generating much lower aliases for decimals (lets say until 1000), droping the other bases, and exporting a function to extended the alias range at will? (that function could perfectly include the other bases as well). Something called extendAliases would do. I don't have the time to work on it now, but if you send me a patch I'd be happy to apply it. It should be something simple to do. All the Template Haskell machinery is already coded.
[…]
Best wishes, Wolfgang