On Wednesday 28 March 2007 17:08, Benjamin Franksen wrote:
Robert Dockins wrote:
Some sort of in-langauge or extra-language support for mechanicly
producing
the source files for the full API from the optimized "core" API would be quite welcome.
Have you considered using DrIFT? IIRC it is more portable and easier to use than TH.
DrIFT only works on datatype declarations (AFAIK) and doesn't really cover the use cases in question. [snip]
haddock comments,
I thought all the documentation would be in the API classes, not in the concrete implementations.
It is now, but I've gotten complaints about that (which are at least semi-justified, I feel). Also, the various implementations have different time bounds which must documented in the individual modules.
Yes, I forgot about that. Hmmm.
Ideally, I'd like to have the function documentation string and the time bounds on each function in each concrete implementation. I've not done this because its just too painful to maintain manually.
I can relate to that. The more so since establishing such time bounds with confidence is not trivial even if the code looks simple. BTW, code generation (of whatever sort) wouldn't help with that, right?
Well, I can't imagine any tool that would prove the bounds for me unless automatic proof techniques have improved a _lot_ in the last week or so ;-) However, if I could record the bounds once somewhere for each implementation and then have them auto merged with the documentation for each function, that would be great.
I wonder: would it be worthwhile to split the package into smaller parts that could be upgraded in a somewhat less synchronous way? (so that the maintenance effort can be spread over a longer period)
Perhaps, but that only amortizes the effort rather than reducing it. [snip]
As I explained to SPJ, I am less concerned with duplicated work when implementing concrete data structures, as with the fact that there is still no (compiler checkable) common interface for e.g. string-like thingies, apart from convention to use similar names for similar features.
Fair enough. I guess my point is that typeclasses (ad per Edison) are only a partial solution to this problem, even if you can stretch them sufficiently (with eg, MPTC+fundeps+whatever other extension) to make them cover all your concrete implementations.
Yes, and I think these problems would be worth some more research effort.
Agreed.
Besides, I dearly hope that we can soon experiment with associated type synonyms...
Cheers Ben
Rob Dockins