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 _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
