[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