About the test suite:
geq - generic equality - Must this be "extensible/specializable" to count? (If so, cannot do with LIGD, SYB1/2.
I wouldn't think so. We can compare implementations on some standard types, and let extensibility/specializability be a separate evaluation criterium.
gshow - Must this be "extensible/specializable" to count? (If so, cannot do with LIGD, SYB1/2). - Must this match "deriving Show" to count? (If so, should be updated for LIGD.)
I think that would be a desirable requirement. Yes, I think the LIGD show example should be updated with a function that places parentheses as deriving Show does.
bits - Must all versions produce the *same* binary format. This seems like a potentially unfair comparison as small details (constructor order in view) can make significant differences. I propose we let each version choose its own binary form, perhaps encouraging each to produce the most compact format possible, while still requiring fromBin . toBin = id. (Currently, SYB doesn't use XBitz because I just copied the example from Ralf's page, but I'd like to change that.)
That makes sense. I can imagine requiring exactly the same binary format would lead to some very nasty implementations for some views.
foldTree - An example from Ralf's SYB webpage. Accumulate all ints in a tree. Then accumulate only those ints wrapped with the "Leaf" constructor.
foldTree is maybe better called crushTree (as Ralf L calls it, after a paper by Lambert Meertens many years ago), to avoid confusion with the `algebraic' fold. I agree it would be nice to add generic crush to the test suite. And maybe even generic fold, but I doubt if there is any appraoch with which generic fold can be nicely defined.
paradise - Another of Ralf's examples. Should the LIGD version count?
This is the increase salaries example, isn't it? I prefer to call it something like increase salaries, or raise salaries, as Oleg calls it (I suppose I don't care about my salary anymore in paradise, that is, if I ever get to go there, of course). And should the LIGD version count? Good question. Without `open datatypes' I would think that this example is not implementable in LIGD, since it requires adapting the library, so we maybe should leave it out.
For all of these examples, there is the question of what tests to run for each. geq, gshow, bits and paradise currently work for the "CompanyDatatypes" (I extended LIGD to cover floats). foldTree works for a specific Tree. Perhaps future examples can stress other datatypes.
Other extensions that we need are some test harness to run all of these tests and create a summary of which frameworks have which tests.
I think we have to create test data types in each category of data types you mentioned in a previous message. And possibly multiple data types in the `standard data types' category. Organizing this shootout is quite a task, I hope we'll find a volunteer to organize it. (I'm afraid my time is too divided to do it.) -- Johan