These are features which we might want to consider for removal or replacement with something better/cleaner.
-
eliminate tab stops in layout
-
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.
- Against removal: Everyone uses them. Lots of legacy code. Expressing recursion over numbers is more verbose without these patterns.
- (JL). Recommend making these monomophic. Either (a) always Integer (or Natural if it gets added), or (b) subject to monomorhism restriction and defaulting.
-
~ patterns
-
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.
-
-
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.
-
record syntax (see also ExistingRecords)
-
the Prelude (or at least, seriously trim it to the minimum possible)
-
classes (no really, there are people who advocate this!)
- (JL) This would so fundamentally change the nature of Haskell as to make it a different language. It is surely out of scope for what we plan to accomplish.
- Helium has no classes, yet is recognisably very Haskell-like.
- A concrete proposal would be to replace classes with named dictionaries that can be constructed and passed around explicitly. See NamedInstances. However this would rule out GADT based class implementations such as jhc's.
-
The array indexing operator,
!. See ArrayIndexing.