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>
