-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Topological Ordering of Specializers #1
Comments
@csrhodes mentioning you so you get notified :) |
As @csrhodes pointed out, the above algorithm will not work in cases like:
and
|
Extended visualization of the above problem with additional edges indicating known disjoint ( Next steps probably are
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As I wrote earlier,
pattern-more-specific-p
establishes a partial orderon patterns which is similar to the subtype relation (See attached
figures for examples; arrows point to "more specific"). The similarity
being that the set of values matching a more specific pattern is a
subset of the values matching a less specific pattern.
Furthermore, the dispatch strategy (considering only one argument and
only pattern specializers) currently looks like this (unchanged compared
to previous email):
The rationale being that a single successful match should be sufficient
to determine all matching patterns (and thus accepting
pattern-specializers) as well as binding the relevant pattern variables.
This assumes that optima is smart enough to avoid unnecessary work when
sequentially trying subsequently less specific patterns (in line 2).
Now the new issue: previously, I assumed patterns would form totally
ordered "clusters" (actually connected components) under
pattern-more-specific-p
. This assumption is reflected in the algorithmabove. However, the assumption is not true (again, see attached figures,
ignore
BUILT-IN-CLASS CONS
…).A new assumption could be that patterns form connected components in a
DAG under
pattern-more-specific-p
. If I'm not mistaken, a suitableadaptation of the above algorithm would then be:
Not sorting connected components for processing should have performance
implications but should not affect the result of the computation since
the sets of matching values should be disjoint.
One potential problem is that
pattern-more-specific-p
employssubtypep
when comparing
(type …)
andclass
patterns (see specializer-dag-2 forexcessive use of
class
patterns), making the resulting orderingspecializer-dag-1:
![specializer-dag-1](https://cloud.githubusercontent.com/assets/150189/3250056/79fb0d88-f1a0-11e3-82af-fdca7495f537.png)
specializer-dag-2:
![specializer-dag-2](https://cloud.githubusercontent.com/assets/150189/3250055/79fa80e8-f1a0-11e3-8b39-0832c1d81c10.png)
The text was updated successfully, but these errors were encountered: