Applications and libraries/Generic programming/Template

From HaskellWiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Approach: The name of the approach

Required features/Portability

  • What do features do we need?

  • What compilers support these features?

Expressibility

  • What kind of generic functions can we write?

  • Can we do producer and consumer functions?

  • Does it support generic functions with different arities?

  • What about local redefinitions?

Subset of data types covered

  • What is the family of data types supported?

Here is a list provided by Stephanie:

  records
  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

Usage

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

Amount of work per data type (Boilerplate)

  • What do we need to do each time we add a new datatype?

Extensibility

  • Is the approach extensible, if not can we do anything about it?

Reasoning

  • How easy is to reason about generic functions with this approach?

Performance considerations

  • what are the performance impacts, is it possible to improve?

Helpful extra features

  • What features could Haskell have that would make the approach easier to use?

  • Are those features realistically feasible?

Discussion

Overall discussion