[Haskell-cafe] Re: Can we do better than duplicate APIs?
robdockins at fastmail.fm
Wed Mar 28 17:05:20 EDT 2007
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.
> >>> 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.
> >> 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.
> Besides, I dearly hope that we can soon experiment with associated type
More information about the Haskell-Cafe