valhalla-dev Digest, Vol 7, Issue 66
twhitmore.nz at gmail.com
Tue Jan 20 01:15:19 UTC 2015
Hi Gavin, Maurizio, Brian,
[Resent from private, thanks Maurizio:]
"Meet rule" is potentially required for this idea of OO dispatch due to the
"open" nature of the subtype/ method declaration universe. By contrast, I
am assuming that specialization space must be completely defined &
fulfilled in each & every method implementation.
No interaction between separate partial spatial coverages, therefore no
need for a meet rule.
> The “meet” terminology comes from maths: given a partially ordered set S,
the meet of a subset of S is the greatest lower bound (if it exists).
> In OO type systems, it is typically used in the context of overloading:
e.g. if you have overloads whose argument types have a common lower
> bound (i.e. a common subtype) then you must have an overload with
argument types of that common lower bound.
> For example, Fortress:
> Except that's exactly how method overload selection works in Java today
; by contrast, there are no left-to-right precedence mechanisms.
> So while you might consider the left-to-right rule "better", when taken
in the context of how the language already works (and how developers
> I think this has to be rejected.
This may be conflating two separate issues. My focus would be on
circumscribing matching into a well-defined & explicitly dimensioned space,
which can be done -- making it a well-structured construct with a "closed
space" which can thus be evaluated/determined independently, rather than an
"open space" where interaction with other declarations/ constructs becomes
The single-dimensional example would be 'switch' statements -- 'case'
clauses live within their 'switch' container, and do not interact.
The other issue is to use a precedence rule within a single system, rather
than a "meet rule" between systems. L-to-R most specific was merely the
first suggestion off the top of my head. Other matching precedence rules
(such as the current Java method resolution rules) would obviously be worth
More information about the valhalla-dev