forked from jckarter/clay
-
Notifications
You must be signed in to change notification settings - Fork 0
Improved overload resolution
prunedtree edited this page Jan 9, 2011
·
25 revisions
Current overloads have two main issues:
- They depend on code position of toplevel definitions (confusing for newbies, manageable for some, unacceptable for others, error-prone for all)
- They depend on module loading order (much more problematic)
various syntaxes are possible....
- Overload blocks
"overload" [ "(" module_list ")" ] "{" [ function_definition ]* "}"
example:
// vectors.clay
// just make the shadow block toplevel, for more regular syntax ?
shadow {
Vector(s:'S) | Sequence?('S) {
...
}
Vector(s:'S) | SizedSequence?('S) {
...
}
Vector(rvalue s:Vector['T]) {
...
}
}
// randomaccesssequences.clay
overload {
Vector(s:'S) | RandomAccessSequence?('S) {
...
}
// forwardsequences.clay
Vector(s:'S) | ForwardSequence?('S) {
...
}
- Overload chain statements
"overload" [ "(" module_list ")" ] function_definition [ "shadow" function_definition ]*
- overloads are a list of function definitions with a list the modules whose definition they shadow
- each module has only one overload list per callable
- definitions within one overload will overload each-other based on definition order (current semantics)
- function definitions outside overload blocks cannot overload other functions
- overload lists with no specified modules implicitly overload all modules
overloads thus form a DAG where every node points to the node it overloads if two definitions are valid, but are unordered according the the DAG, then that ambiguity is a static error
Please add comments here.