(I have split this discussion from the original mail:
Remove predicate, since the topic is now rather different.)
I see the built-in equality that goes hand in hand with matching/unification as the primary equality. Any other equality must be secondary.
<> is defined as the negation of =, the other relational operators <, <= , etc could/can be defined in many ways but they must respect = (if A = B then A cannot be smaller than B on the other hand it must be smaller or equal to B). So primary comparator can be primary must fulfill this requirement (for all
A and
B):
This is on top of these relations that must apply to any comparator
Code: Select all
compare(A, B) = equal <=> compare(B, A) = equal
compare(A, B) = greater <=> compare(B, A) = less
All those words are merely explaining that any custom comparison must in some sense become a secondary comparison.
But it could of course still be the case that the secondary custom comparison is used by default in some situations, for example as map-key comparator. But what about list sorting, removal of duplicates, etc should they all start using the custom comparator?
In simple cases I think this would be relatively easy to deal with, give that we still have access to both comparators.
The really problematic thing is when domains are used to define other domains:
Code: Select all
domains
neutralString = string [comparator(string::compareCaseNeutral)].
domains
ddd = ddd(neutralString NS).
myDomain = md(neutralString S, ddd D).
The custom comparator for
myDomain will use the custom comparator for
neutralString for the first argument. It will also use the custom comparator for
ddd which in turn uses the custom comparator for
neutralString.
The problem is that we now have access to two comparators on myDomain the custom comparator that uses custom compare in all levels, and then the built-in comparator that uses built-in comparison in all levels.
So it is
all or nothing but I believe you will actually very often need some "in between" like: Built-in compare on outer level, but still custom compare on inner levels (which is in many cases defined in a completely different context).
You can of course still handle such situations by writing yet another comparator, but then it seems that the benefit was not that big after all.