... | ... | @@ -9,18 +9,20 @@ These are features which we might want to consider for removal or replacement wi |
|
|
- k patterns, that is, numeric literals
|
|
|
|
|
|
- For removal: Overloaded numeric patterns mean there is hidden computation going on during LHS matching.
|
|
|
Nine times out of ten, what is really wanted is Natural numbers, not Integers (and definitely never Floats!).
|
|
|
This language feature also makes the implementation of code-transformation tools more tricky and less regular.
|
|
|
Nine times out of ten, what is really wanted is [Natural numbers](natural), not Integers (and definitely
|
|
|
never Floats!). This language feature also makes the implementation of code-transformation tools more tricky
|
|
|
and less regular.
|
|
|
- Against removal: Everyone uses them. Lots of legacy code. Expressing recursion over numbers is more verbose
|
|
|
without these patterns.
|
|
|
- [NegativeSyntax](negative-syntax)
|
|
|
- \~ patterns
|
|
|
|
|
|
- For removal: can be simulated with 'where' or 'let' clauses
|
|
|
- Against removal:
|
|
|
- For removal: can be simulated with 'where' or 'let' clauses
|
|
|
- Against removal:
|
|
|
|
|
|
- fine control of strictness can require careful placement of these and let/where would obscure what is happening and get very verbose with nested \~ patterns.
|
|
|
- are used in several safe programing idioms that would not be workroundable.
|
|
|
|
|
|
- fine control of strictness can require careful placement of these and let/where would obscure what is happening and get very verbose with nested \~ patterns.
|
|
|
- are used in several safe programing idioms that would not be workroundable.
|
|
|
- class contexts on data definitions
|
|
|
|
|
|
- For removal: they add no extra useful expressivity that is not already present in the function signatures which use the datatype.
|
... | ... | |