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

[Benjamin Franksen]

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.

>>> Handling export lists, 
>>
>> How so? I thought in Edision the API is a set of type classes.  
>> Doesn't that
>> mean export lists can be empty (since instances are exported
>> automatically)?
> 
> No.  Edison allows you to directly import the module and bypass the  
> typeclass APIs if you wish.

Ah, I didn't know that.

> Also, some implementations have special   
> functions that are not part of the general API, and are only  
> available via the module exports.

Ok.

> One could make typeclasses the only way to access the main API, but I  
> rather suspect there would be performance implications.  I get the  
> impression that typeclass specialization is less advanced than  
> intermodule inlining (could be wrong though).

No idea. Experts?

>>> 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?

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)

>>> I have to admit, I'm not sure what an in-language mechanism for doing
>>> something like this would look like.  Template Haskell is an  
>>> option, I
>>> suppose, but its pretty hard to work with and highly non- 
>>> portable.  It
>> also
>>> wouldn't produce Haddock-consumable source files.  ML-style first  
>>> class
>>> modules might fit the bill, but I'm not sure anyone is seriously
>> interested
>>> in bolting that onto Haskell.
>>
>> 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
synonyms...

Cheers
Ben