Difference between revisions of "Applications and libraries/Generic programming/Template"

From HaskellWiki
Jump to: navigation, search
 
 
Line 5: Line 5:
 
<ul>
 
<ul>
 
<li><p>What do features do we need?</p></li>
 
<li><p>What do features do we need?</p></li>
<li><p>What compilers support these features?</li></p>
+
<li><p>What compilers support these features?</p></li>
 
</ul>
 
</ul>
   
Line 11: Line 11:
   
 
<ul>
 
<ul>
<li><p>What kind of generic functions can we write?</li></p>
+
<li><p>What kind of generic functions can we write?</p></li>
<li><p>Can we do producer and consumer functions?</li></p>
+
<li><p>Can we do producer and consumer functions?</p></li>
<li><p>Does it support generic functions with different arities?</li></p>
+
<li><p>Does it support generic functions with different arities?</p></li>
<li><p>What about local redefinitions?</li></p>
+
<li><p>What about local redefinitions?</p></li>
 
</ul>
 
</ul>
   
Line 20: Line 20:
   
 
<ul>
 
<ul>
<li><p>What is the family of data types supported?</li></p>
+
<li><p>What is the family of data types supported?</p></li>
 
</ul>
 
</ul>
   
Line 68: Line 68:
 
<ul>
 
<ul>
 
<li><p>what are the kind of type- error messages you get when
 
<li><p>what are the kind of type- error messages you get when
you make a mistake in your generic function?</li></p>
+
you make a mistake in your generic function?</p></li>
 
</ul>
 
</ul>
   
Line 74: Line 74:
   
 
<ul>
 
<ul>
<li><p>What do we need to do each time we add a new datatype?</li></p>
+
<li><p>What do we need to do each time we add a new datatype?</p></li>
 
</ul>
 
</ul>
   
 
== Extensibility ==
 
== Extensibility ==
 
<ul>
 
<ul>
<li><p>Is the approach extensible, if not can we do anything about it?</li></p>
+
<li><p>Is the approach extensible, if not can we do anything about it?</p></li>
 
</ul>
 
</ul>
   
Line 85: Line 85:
   
 
<ul>
 
<ul>
<li><p>How easy is to reason about generic functions with this approach?</li></p>
+
<li><p>How easy is to reason about generic functions with this approach?</p></li>
 
</ul>
 
</ul>
   
Line 91: Line 91:
   
 
<ul>
 
<ul>
<li><p> what are the performance impacts, is it possible to improve?</li></p>
+
<li><p> what are the performance impacts, is it possible to improve?</p></li>
 
</ul>
 
</ul>
   
 
== Helpful extra features ==
 
== Helpful extra features ==
 
<ul>
 
<ul>
<li><p> What features could Haskell have that would make the approach easier to use?</li></p>
+
<li><p> What features could Haskell have that would make the approach easier to use?</p></li>
<li><p>Are those features realistically feasible?</li></p>
+
<li><p>Are those features realistically feasible?</p></li>
 
</ul>
 
</ul>
   

Latest revision as of 06:57, 24 December 2013

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