High Leslie, AH, YES! Just a slip of the keyboard. It’s so easy to miss significant semicolons.
Good to know everything is in order. pheeew, I was also worried. Many thanks for sorting that out. cheers, Robbert. > On 27 Feb 2015, at 02:41, Leslie Schultz <[email protected]> wrote: > > Hey Robbert- > > This potential problem really had Todd and Mark worried, but they're > neck-deep in > macros so they put Rich and me on it straightaway. > > You used a semicolon instead of a comma to separate the fields in the class > declarations. So instead of A and B having two fields each, they both only > have > one field, and the lines starting "field2" are interpreted as variable > declarations. With commas instead, the subtype expressions both evaluate to > false. > > On the plus side, this has prompted us to consider making it either a warning > or > an error to indent a top-level statement. > > Happy Friday to you! > > Leslie > > Mark van Gulik wrote: >> >> With A and B as you defined them, neither A ⊆ B nor B ⊆ A should be true. >> We’ll run some tests in a little while to see if we can identify the source >> of >> this problem. >> >> In general, the types form a lattice, but more importantly, they’re a partial >> order. So X and Y can be related in one of the following four ways: >> 1. X is a proper subtype of Y >> 2. Y is a proper subtype of X >> 3. neither >> 4. X = Y >> These can be distinguished with the ⊆ operator by testing both X⊆Y and Y⊆X. >> If >> they’re <true,false>, it’s case 1; if they’re <false, true>, it’s case 2; if >> they’re both false it’s 3, otherwise they’re both true and it’s case 4. >> >> We do a similar thing with A_Number, when we perform a /numeric/ comparison >> (note that this is unrelated to Avail equality). It returns an instance of >> AbstractNumberDescriptor.Order, which is an enumeration of {LESS, MORE, >> EQUAL, >> INCOMPARABLE}. This was needed because some floating point numbers are >> incomparable with everything else ("NaN”s). What gets exposed in primitives >> loses this distinction, but it can be reconstituted by running "_≤_” each >> way, >> just like for the type partial order. >> >> >>> >>> On Feb 26, 2015, at 6:22 PM, Robbert van Dalen <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> I’m very sure "_⊆_” is not symmetric, everything else is still open >>> questions. >>> >>>> >>>> On 27 Feb 2015, at 01:12, Robbert van Dalen <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Hi, >>>> >>>> I have the following code the returns true on “test" >>>> >>>> "field1" is a new field atom; >>>> "field2" is a new field atom; >>>> >>>> class "A" extends object >>>> with fields >>>> field1 : number; >>>> field2 : float; >>>> >>>> class "B" extends object >>>> with fields >>>> field1 : float; >>>> field2 : number; >>>> >>>> Public method "test" is >>>> [ >>>> B ⊆ A >>>> ]; >>>> >>>> Shouldn't both B ⊆ A and A ⊆ B return false? >>>> Is the subtype/supertype relation symmetric? >>>> >>>> Or alternatively, should "_⊆_" return a three-valued result? i.e. >>>> false/true/don’t know. >>>> >>>> cheers, >>>> Robbert. >>> >>> >> > > > Mark van Gulik wrote: >> With A and B as you defined them, neither A ⊆ B nor B ⊆ A should be true. >> We’ll >> run some tests in a little while to see if we can identify the source of this >> problem. >> >> In general, the types form a lattice, but more importantly, they’re a partial >> order. So X and Y can be related in one of the following four ways: >> 1. X is a proper subtype of Y >> 2. Y is a proper subtype of X >> 3. neither >> 4. X = Y >> These can be distinguished with the ⊆ operator by testing both X⊆Y and Y⊆X. >> If >> they’re <true,false>, it’s case 1; if they’re <false, true>, it’s case 2; if >> they’re both false it’s 3, otherwise they’re both true and it’s case 4. >> >> We do a similar thing with A_Number, when we perform a /numeric/ comparison >> (note >> that this is unrelated to Avail equality). It returns an instance of >> AbstractNumberDescriptor.Order, which is an enumeration of {LESS, MORE, >> EQUAL, >> INCOMPARABLE}. This was needed because some floating point numbers are >> incomparable with everything else ("NaN”s). What gets exposed in primitives >> loses this distinction, but it can be reconstituted by running "_≤_” each >> way, >> just like for the type partial order. >> >> >>> On Feb 26, 2015, at 6:22 PM, Robbert van Dalen <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> I’m very sure "_⊆_” is not symmetric, everything else is still open >>> questions. >>> >>>> On 27 Feb 2015, at 01:12, Robbert van Dalen <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Hi, >>>> >>>> I have the following code the returns true on “test" >>>> >>>> "field1" is a new field atom; >>>> "field2" is a new field atom; >>>> >>>> class "A" extends object >>>> with fields >>>> field1 : number; >>>> field2 : float; >>>> >>>> class "B" extends object >>>> with fields >>>> field1 : float; >>>> field2 : number; >>>> >>>> Public method "test" is >>>> [ >>>> B ⊆ A >>>> ]; >>>> >>>> Shouldn't both B ⊆ A and A ⊆ B return false? >>>> Is the subtype/supertype relation symmetric? >>>> >>>> Or alternatively, should "_⊆_" return a three-valued result? i.e. >>>> false/true/don’t know. >>>> >>>> cheers, >>>> Robbert. >>> >> > > -- > Leslie Schultz > The Avail Foundation, LLC > www.availlang.org <http://www.availlang.org> >
signature.asc
Description: Message signed with OpenPGP using GPGMail
