type checker appears to find missing library definition for MAX and MIN for ZZ32

[steve.heller]

The following code does not type check unless I un-comment out the definitions of the MIN and MAX oprs especially for ZZ32.

component tryit (* trying out stuff *)
export Executable

(*
opr MIN(a:ZZ32,b:ZZ32):ZZ32 = if a<b then a else b end
opr MAX(a:ZZ32,b:ZZ32):ZZ32 = if a>b then a else b end
*)

object trip (a:ZZ32, b:ZZ32, c:ZZ32) end trip
orderedTrip(a:ZZ32, b:ZZ32, c:ZZ32):trip =
    trip ((a MIN b), (a MAX b), c)

run(args:String...) = do end
end tryit

[steve.heller]

I forgot to include the result of type-checking:

-*- mode: compilation; default-directory: "~/programs/fortress/" -*-
Compilation started at Mon Sep 15 16:19:04

~/PFC/bin/fortress typecheck tryit.fss
Guessing FORTRESS_HOME=/Users/steve/PFC
/Users/steve/programs/fortress/tryit.fss:14:4-34: Applicable overloading of function trip could not be found for argument type ((AND{FortressLibrary.ZZ[\\],FortressLibrary.QQ[\\]},AND{FortressLibrary.ZZ[\\],FortressLibrary.QQ[\\]},FortressLibrary.ZZ32[\\]))
File tryit.fss compiled with 1 error.

Compilation finished at Mon Sep 15 16:19:10

[jmaessen]

Hmm, this may be due to the curious and convoluted nature of the type hierarchy, but I still think it's getting it wrong.

The type hierarchy looks like this. The asterisks mark where concrete method definitions for MIN can be found.

StandardMin[\T\]@
     |        \
  *Number StandardTotalOrder[\T\]*
     |         |
   RR64   Integral[\I\]
     |   /  / /
   *QQ  /  / /
     | /  / /
    ZZ   / /
     |  / /
    ZZ64 /
     |  /
    ZZ32

The @ marks the abstract declaration for opr MIN (the type StandardMax works exactly the same way for opr MAX). Note the multiple extension of StandardMin and Integral at different parameterizations. Note also that there are no less than five different possible concrete overloadings of opr MIN for which the type of self is ZZ32. However, there is no conflict among these overloadings; they ought to satisfy the subtype rule.

What baffles me is why the type checker appears to be considering only the overloadings at QQ and ZZ, given the fact that all variables are exhaustively indicated to have type ZZ32. It might be instructive to bind the subexpression in question with an explicit type annotation and see what happens. I feel like what we're seeing is the LUB of the type constraints on the overloadings, whereas we probably want to narrow to the actual applicable overloadings first and then apply LUB. But I'm guessing as a type-checker outsider. I just wanted to shed some light on the type hierarchy involved, as it's pretty twisty and I spent a bit of effort assuring myself that it's not blatantly wrong (eg I'd almost convinced myself that there might be ambiguous method overloadings hiding here).

So I think what's going on here is we've actually got an ambiguous overloading-we can get opr MIN from either , and neither the interpreter nor the static checker are correctly signaling it.

[jmaessen]

Er, strike the last paragraph from my previous comment. Its inclusion was from a previous edit, and it's saying the wrong thing the last sentence of the previous paragraph mentions.