Linearity Requirement for Patterns
What is the reasoning for the requirement that patterns be linear? Am I correct to say that if non-linear patterns were allowed, it would require equality to be defined for all data types? Is this the reason, or are there others? Sam Moelius
"Samuel E. Moelius III" wrote:
What is the reasoning for the requirement that patterns be linear? Am I correct to say that if non-linear patterns were allowed, it would require equality to be defined for all data types? Is this the reason, or are there others?
If that were the reason, then to be consistent, there would be no literals in patterns, as these are tested using equality. Here is a reason. Some people believe that the equations that form a function definition should be disjoint. A good reason for this view is that fold/unfold transformations can be then performed without reference to the other cases in the definition - if it matches, it is correct to use it. Although Haskell does not require disjoint cases, and defines the semantics in terms of a top-to-bottom testing order, the rejection of non-linear patterns was largely because it is not generally possible to specify, as a pattern, the complement of the set of values that match a non-linear pattern, and so not possible to write a set of disjoint case equations if non-linear patterns occur. In any case, the same effect can be obtained using guards, where the extra power of expression syntax solves the problem. Instead of f x x = e1 f (illegal pattern) = e2 ... you can write the single equation f x y | x == y = e1 | x /= y = e2 --brian
On Sat, Mar 17, 2001 at 03:49:15PM +1300, Brian Boutel wrote:
"Samuel E. Moelius III" wrote:
What is the reasoning for the requirement that patterns be linear? Am I correct to say that if non-linear patterns were allowed, it would require equality to be defined for all data types? Is this the reason, or are there others?
If that were the reason, then to be consistent, there would be no literals in patterns, as these are tested using equality.
Only numeric literals actually use the '==' operator, correct? (As opposed to built-in equality for data constructors and characters.) --Dylan Thurston
Fri, 16 Mar 2001 23:14:17 -0500, Dylan Thurston
If that were the reason, then to be consistent, there would be no literals in patterns, as these are tested using equality.
Only numeric literals actually use the '==' operator, correct?
Yes. This is a hack which allows viewing numeric types as algebraic types with many constructors, assuming that (==) definition is sane. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK
Dylan Thurston wrote:
Only numeric literals actually use the '==' operator, correct? (As opposed to built-in equality for data constructors and characters.)
I should have been more specific. Not that it affects the point being made, and I didn't want to lose that in the detail. Pattern matching for numeric literals uses whatever (==) has been defined for the type, except, of course for the literals in n+k patterns where (>=) is used. The Character type is treated as a set of data constructors. Data constructors match if they are the same constructor, and fail to match otherwise. This is not the same as equality, where you are free to define any result when comparing values, but it is the same as the equality that would be derived for a type that consisted of a set of nullary constructors. String literals are lists of characters. Consequently, string matching will use constructor matching for the List constructors and for the characters. So, yes, (==) is used when matching most numeric literals, and not used for other literals. --brian
participants (4)
-
Brian Boutel -
Dylan Thurston -
qrczak＠knm.org.pl -
Samuel E. Moelius III