[Haskell-cafe] Re: Can we do better than duplicate APIs?

[Robert Dockins]

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