David> Oh, easily solved: "in the face of ambiguity, refuse the
David> temptation to guess". There should be a best match rule, and
David> if there are two best matches, it's an error.
In the ML example I showed earlier:
fun len([]) = 0
| len(h::t) = len(t) + 1
ordering is crucial: As long as the argument is not empty, both cases
match, so the language is defined to test the clauses in sequence.
My intuition is that people will often want to define category tests
to be done in a particular order. There is no problem with such ordering
as long as all of the tests are specified together.
Once the tests are distributed, ordering becomes a problem, because
one person's intentional order dependency is another person's
ambiguity. Which means that how one specifies distributed tests will
probably be different from how one specifies tests all in one place.
That's yet another reason I think it may be right to consider the
two problems separately.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4