Difference between revisions of "Applications and libraries/Generic programming/Template"
Misterbeebee (talk | contribs) |
|||
| 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>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>What kind of generic functions can we write?</p></li> |
| − | <li><p>Can we do producer and consumer functions?</ |
+ | <li><p>Can we do producer and consumer functions?</p></li> |
| − | <li><p>Does it support generic functions with different arities?</ |
+ | <li><p>Does it support generic functions with different arities?</p></li> |
| − | <li><p>What about local redefinitions?</ |
+ | <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>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?</ |
+ | 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>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>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>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> 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> What features could Haskell have that would make the approach easier to use?</p></li> |
| − | <li><p>Are those features realistically feasible?</ |
+ | <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