Dynamic type conversions

[Ajrat]

Cobra Command Line svn:2874 (post 0.9.3) / 2012-12-16
Copyright (C) 2003-2012 by Cobra Language LLC.

OS Version: Microsoft Windows NT 6.1.7601 Service Pack 1
CLR Platform: .NET
CLR Version: 4.0.30319.17929

Code: Select all

1    class Program
2        shared
3
4            def add(x, y) as dynamic
5                return x + y
6      
7            def main
8                print '*****Fun with type conversions *****'
9                numb1 as int16 = 9
10               numb2 as int16 = 10
11               print '[numb1] + [numb2] = [.add(numb1, numb2)]'


When I run the above, I experience...

Unhandled exception: Cobra.Core.UnknownMemberException: obj=9 (Int16), nam
e='op_Addition or op_Addition_Int16_Int16', type=System.Int16
in Cobra.Core.CobraImp.DynamicOp(String opMethodName, Object value1, Object va
lue2, Boolean promote)
in Cobra.Core.CobraImp.DynamicOp(String opMethodName, Object value1, Object va
lue2)
in Program.Main() в c:\workspace_Cobra\TypeConversions\Program.c
obra:line 11

[hopscc]

Yeees.

cobra fails in this manner because the cobra RunTimeLib doesnt have support for dynamically typed operations (addition in this case) on int16 types.
Int32 are fully supported so a workaround would be casting or otherwise using Int32 types in your call ( or explicitly typing your .add method)

I'm not sure what the intention is here, as to fully support dynamic types and arithmetic operations in this manner suggests a combinatorial explosion of RTL support methods (number of arithmetic operations * number-of-numeric-types-factorial/2).

perhaps this could be better supported using a genericised RTL support method and some changes to codegen to use it (??)
Chuck?

[Charles]

I'm taking a look. There's no good way in .NET to constrain a generic parameter to "any sized" int, but there are possibly some other options.

It is unusual to see 16-bit ints and dynamic used together. The motivation for small ints is usually efficiency and the motivation for dynamic is flexibility at the cost of efficiency.

[hopscc]

Off the top of my head I was thinking more along the lines of a RTL method genericised by type

Code: Select all

static public T1 op_Add<T1, T2>(T1 a, T2 b) {
   return a + b;
}


then the code gen rather than generating an exact named by type RTL method call
op_Add_int16_int16(a,b)
generates a type specified (type collapsed?) call to the generic method
op_Add<int16, int16>(a,b)

The other thought would be to have the RTL method use the widest or most common type ( int32 or int64) with a generic name
and rely on the compiler to match the call widening the args as it can - other parts of the RTL seem to use that (??)

Code: Select all

static public int32 op_add( int32 a, int32 b) { return a + b; }


code gen just calls op_add with the narrower typed ints - compiler auto widens

or alternatively codegen explicitly casts the ints to the wider type into the call and casts back down (perhaps with masking) on receipt

Code: Select all

(int16)op_Add((int32)a. (int32)b)


[hopscc]

Looks like we already knew about this - theres an existing ticket for this already
ticket:171

[Charles]

I fixed this, at least for some cases. Since .NET runs on 32-bit (and 64-bit) systems, the run-time code will now promote to 32-bit ints before performing the operation which I think will be sufficient. 16-bits saves memory when packed in arrays and such, but there is no performance improvement for a 32-bit chip.

There may be other cases awaiting our attention, but at least this one is resolved (along with int8, and also X unsigned).

[nerdzero]

Does promoting break bitmasking on if conditions?

[Charles]

I don't see how it would, but if you had a specific case in mind, throw me some code.

[nerdzero]

Okay, I tried to come up with an example off the top of my head but I couldn't. I feel like getting more bits than expected will introduce bugs. I'm gonna play with this...

edit: Well, seems fine. The best I could do was muck it up trying to cast the result back to int16. Also, after a bit of reading this is how it works when strongly typed anyways Doh!

[Charles]

Btw I doubt people who are doing bitwise operations are using dynamically typed data. Partial classes, extension methods, multi-line strings and autocompletion are all 100 X more interesting.