[kepler-dev] Question about OrderedRecordToken
Edward A. Lee
eal at eecs.berkeley.edu
Sat Dec 5 08:24:10 PST 2009
One possibility would be to not perform the addition if
the ordering is not the same. This would be consistent
with the fact that
[x = 1, y = 2] != [y = 2, x = 1]
and that their types are different.
I'm not sure about this though...
Edward
ben leinfelder wrote:
> Edward,
> I'm not sure what determines the order of the result when you add
> ordered record tokens - what do you suppose the order should be? With
> the example you have, I don't see a pattern. It's not even defaulting to
> the RecordToken ordering (alpha).
> Does it make sense to have the result use the same ordering as the
> initial operand? Or should the operation fail when the tokens are not in
> the same order (seems severe)?
>
> I'd expect
> a.getType()
> to return
> object([x=int, y=int])
> It seems to be deferring to the superclass for getType...something I
> should look into/fix.
>
> Thanks for pointing these out.
> -ben
>
> On Dec 4, 2009, at 6:51 AM, Edward A. Lee wrote:
>
>>
>> Ben,
>>
>> I have a question about ordered record tokens.
>> In the expression evaluator, I can do:
>>
>> >> a = [x = 1, y = 2]
>> [x = 1, y = 2]
>>
>> >> c = [y = 2, x = 3]
>> [y = 2, x = 3]
>>
>> >> a + c
>> [y = 4, x = 4]
>>
>> >> c + a
>> [y = 4, x = 4]
>>
>>
>> What determines the order in the result?
>>
>> Also, if I do:
>>
>> >> a.getType()
>> object({x = int, y = int})
>>
>> This description of the type seems exactly the same as
>> the description I get from an (unordered) record token.
>> Is this a problem? (I don't really know...)
>>
>> Thanks!
>> Edward
>> <eal.vcf>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eal.vcf
Type: text/x-vcard
Size: 351 bytes
Desc: not available
URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20091205/259f169c/attachment.vcf>
More information about the Kepler-dev
mailing list