Applications and libraries/Generic programming/Template

From HaskellWiki
< Applications and libraries‎ | Generic programming
Revision as of 12:53, 11 May 2007 by Johanj (talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Approach: The name of the approach

Required features/Portability

  • What do features do we need?

  • What compilers support these features?</li>


  • What kind of generic functions can we write?</li>

  • Can we do producer and consumer functions?</li>

  • Does it support generic functions with different arities?</li>

  • What about local redefinitions?</li>

Subset of data types covered

  • What is the family of data types supported?</li>

Here is a list provided by Stephanie:

  nested datatypes
  higher-kinded types (what kinds?)
  datatypes with existential components (both of kind type and  
  higher kinds)
  datatypes with first-class polymorphic components (both of kind  
  type and higher kinds)
  above with class constraints
  GADTs (simple, and those that subsume existentials...)
  datatypes with higher-kinded type arguments


  • How to use the library?

  • What different kinds of users do we have?

Stephanie Weirich gave a good description of possible users of the library. Here is that description (slightly modified):

A Generic library has several important components: the "framework" or way of representing a particular type, instances of this framework for the primitive types, helper functions for creating instances for new types, and a base set of generic operations/support code to get things started. The "Library writer" is responsible for all of these.

A user of the generic library may want to do two things:

  (a) define new type-indexed functions
  (b) ensure that their datatypes can be used with type-indexed functions

In Bruno's terminology,

  - Power User: does both of these
  - User: does (b) but not (a)
  - End User: does neither, just calls existing type-indexed functions on existing datatypes.

Note that we could imagine eliminating/automating (b) for some platforms with Template Haskell or an external tool like DrIFT.

Error Messages

  • what are the kind of type- error messages you get when you make a mistake in your generic function?</li>

Amount of work per data type (Boilerplate)

  • What do we need to do each time we add a new datatype?</li>


  • Is the approach extensible, if not can we do anything about it?</li>


  • How easy is to reason about generic functions with this approach?</li>

Performance considerations

  • what are the performance impacts, is it possible to improve?</li>

Helpful extra features

  • What features could Haskell have that would make the approach easier to use?</li>

  • Are those features realistically feasible?</li>


Overall discussion