You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
concrete TestCnc of Test = {
param
Colour = Black | White ;
Size = Big | Small ;oper
Rec: Type = {
c: Colour ;
s: Size ;
} ;
mkRec0: Rec -> Rec =\r ->lin C r ;
mkRec = overload {
mkRec: Colour -> Size -> Rec =\c,s ->lin C { c = c; s = s } ;
mkRec: Rec -> Rec = mkRec0 ;
} ;lincat
C = Rec ;lin
f1 = mkRec White Small ;-- ok
f2 = mkRec0 { s = Small ; c = White } ;-- ok
f3 = mkRec0 { c = White ; s = Small } ;-- ok
f4 = mkRec { s = Small ; c = White } ;-- ok
f5 = mkRec { c = White ; s = Small } ;-- fails
}
Error for f5:
TestCnc.gf:28:
Happened in linearization of f5
no overload instance of TestCnc.mkRec
with value type {s : Size; c : Colour}
for argument list
{c : Colour; s : Size}
among alternatives
Colour Size
{s : Size; c : Colour}
The enforced order does not seem to be alphabetical (as previously suspected).
The text was updated successfully, but these errors were encountered:
There was an easy fix on line 404, to sort the fields uniformly with sortRec.
For historical reasons, sorting places the 's' field first, other fields alphabetically.
Issue #66 is trickier, since it has to do with the order of record extension and overload resolution in the type checker. I will look at it next. I wrote this code basically in 2006, with a few fixes at later dates.
Originally reported by Roman Suzi in gf-dev.
When using an overloaded oper with a record as an argument, the order of that record's fields matters:
Error for
f5
:The enforced order does not seem to be alphabetical (as previously suspected).
The text was updated successfully, but these errors were encountered: