Am Samstag, 2. Februar 2008 14:54 schrieben Sie:
On Feb 1, 2008 10:32 PM, Wolfgang Jeltsch wrote:
Am Freitag, 1. Februar 2008 13:00 schrieb Alfonso Acosta:
[…]
To make it friendlier for the end user I thought about defining aliases for lets say the first 10000 numbers using Template Haskell. That could even make error reports friendlier (not sure to what point though). What do you think?
I have no clear opinion about that at the moment. Maybe it's okay to use the representation directly. This way, we don't introduce a dependeny on the Template Haskell language extension (which is only supported by GHC), and the actual representation will occur in error messages anyway whenever the message shows a computed number.
Well, my EDSL already makes extensive use of TH. So, being selfish, it wouldn't be a problem for me (or any other GHC user) and I think it would make the library much more usable.
Hello again, 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. 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? 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.
[…]
Best wishes, Wolfgang