On Fri, Mar 14, 2008 at 9:58 PM, Wolfgang Jeltsch
Am Freitag, 14. März 2008 17:46 schrieben Sie:
I think that removing aliases completely is not a good idea. How about generating much lower aliases for decimals (lets say until 1000),
I don't think, this is a good idea. Like nobody will need an alias for 8247, nobody will need an alias for 824. The main point is that it is unnecessary to have a continuous range of numbers for which aliases exist. If you need aliases, you need them for "outstanding" values. Maybe you need aliases for all powers of 2 up to a certain number. Or aliases for all square numbers.
Therefore I think that if we want aliases then we should let the user and only the user generate them. This has also the interesting consequence that the type-level package doesn't need the Template Haskell language extension anymore. After all, using the template-haskell package doesn't imply that you have to have a TH-enabled compiler, as far as I know.
I don't agree. Not using aliases is a big pain, which means that every user wanting to use vectors with sizes biger than 10 (i.e. all) will have to generate their own alias set. It would be really annoying having to generate the aliases every time the library is used. Let's agree on a minimum alias set likely to be used by most of the users, small enough to get a reasonable object code size and compile time (we can even prevent haddock from parsing the alias module and just write a comment indicating what aliases are and which ones are generated if that helps). Generating type redefinitions up to decimal 500 shouldn't be such a big overhead (at least compared to the quntity of aliases generated right now).
droping the other bases,
That's a good idea.
and exporting a function to extended the alias range at will?
I'd rather propose something like this:
$(numAliasDecls [2 ^ n | n <- 0..16])
So that numAliasDecls has a type like [Int] -> [Decl].
That doesn't include bases, which might be important for the end user (for example Oleg wrote his type-evel numerical library in base 2 because it was aimed at system development). I'd rather propose a modification of Data.TypeLevel.Num.Aliases.genAliases which probably should be aware of the aliases already generated in the library so that they are not duplicated.