Thu, 22 Jan 2004 17:04:43 -0500 (EST)
> > Then we just (stable) sort the overloads by priority and resolve.
> I don't see why you need a stable sort but otherwise this makes
Well, a stable sort preserves the order in which the overloaded
identifiers appeared in the source program. I don't see why the overloads
need to be resolved in this order, but the resolve function in
overloads.sml:2224 specifically reverses the overloads list before
resolving each one.
> There is another approach, which is to implement a more powerful
> overloading resolution algorithm that considers all of the overloading
> to be resolved as a set of constraints and finds a solution (if there
> is one) to all the constraints at once. Although more difficult than
> priorities, I might prefer that, since it has a less operational feel.
> But, since the overloading in SML is fixed and the priorities are
> sufficient to implement it, it feels a bit like a waste of time ...
I agree that overloading in SML is a bit broken and something more
powerful would be required if the overloading weren't fixed.