Treat So (f x y z)
and f x y z = True
arguments of constructors specially during derivation
#127
Labels
code: enhancement
New feature or improvement
code: heuristics
Involves solution that applied only to a specific case
derive: least-effort
Relates to the `LeastEffort` derivation algorithm
issue: performance
When work takes too much resources
part: derivation
Related to automated derivation of generators
status: discussion
Suggested or reported thing is not obvious to be good enough
status: feature request
Request for new functionality or improvement
If constructor's argument is of form
So $ f x y z
orf x y z = True
orTrue = f x y z
(for whatever functionf
and whatever count of its arguments), and if we can inspect thisf
, we can optimise generation to be more constructive, instead of filtering, during generation.What we can do is to generate a special data type definition
F
so that iff : X -> Y -> Z -> Bool
,F
would bedata F : X -> Y -> Z -> Type
so that bothhold.
This means that we can replace
So $ f x y z
and/orf x y z = True
argument byF x y z
without any change in the meaning.Thus, we can replace
isJust m = True
withIsJust m
, andelem x xs
withElem x xs
. Generators derived with such a trick would be much more performant, since they would not compute direct function, instead they would constructively generate appropriate values.Beware of thoughts of general replacement of, say, functions like
elem x xs
toElem x xs
and corresponding getting the value out of thisElem
! In the context of returningTrue
this change seems to be appropriate, where in the general case the order of pattern-matching in a function is significant, whereas the order of generations of constructors in corresponding type is not. This approach is appropriate only for functions with non-overlaping clauses.The text was updated successfully, but these errors were encountered: