small int updates

[TimWhiting]

Some missing small int functions, including boxing 8bit integers, which the compiler generated calls to, but did not have appropriate definitions for.

Question for Daan, why do we not have unsigned versions of integers as well?

[TimWhiting]

Also added effect annotation to vector-init. Missed it when fixing effect annotations before. That is unless there is a reason for disallowing all effects there. It seems like for example if you wanted to initialize a vector with random numbers, or wanted to use a local variable and increment it as you go along the vector, it would be impossible without first creating a list, which seems inefficient.

Fixes #391

[iacore]

Hello @TimWhiting can you incorporate #323 in this PR?

[mtoohey31]

@iacore are you referring to the changes in #323 on the KK_INTF_SIZE<=1 branches? If you're talking about something else then please disregard. But if so, from my understanding of the definitions in kklib/include/kklib/platform.h, those branches might be redundant since it seems that the minimum value of KK_INTF_SIZE is 2.

[iacore]

ok closing #323

[mtoohey31]

Alright, thanks @iacore. Maybe don't delete the branch just yet though if you don't mind so we can get a second opinion on whether not the KK_INTF_SIZE<=1 cases are necessary, cause the definitions in kklib/include/kklib/platform.h are a little hard to follow so I'm not 100% sure if I'm right.

[TimWhiting]

Yes, I do think that the #if (KK_INTF_SIZE<=1) conditionals are unnecessary. intf_size is the largest size integer that fits into a machine register. I don't think we plan on supporting any 8 bit platforms. So KK_INTF_SIZE is always either 2, 4 or 8. (16 bit, 32 bit or 64 bit).

The current PR should cover the necessary changes for boxing 8 bit values.

[daanx]

Thanks -- I will add the int8_box/unbox and the effect annotations, but not (yet) the int8/int16 operations.

The idea is that we should always use (arbitrary precision) int 's in Koka as these are well behaved. The int8/16/32/64, ssize_t, and intptr_t are only there for interfacing to external libraries. Now, int32 and int64 have actual operations defined in std/num/int32 and std/num/int64 but this is mostly for specialized use cases like crypto or random. Moreover, we will not add unsigned variants -- but note that std/num/intxx provide ways to interpret a result as unsigned (or convert from int unsigned) (uint64,uint) as well as unsigned multiply (umul) so we can still perform unsigned operations. Again, regular code should just always use int . There are no modules for int8 or int16 as I think there is no good reason for doing mod-2^x operations on those (although I can imagine having simd operations in the future for those)

Furthermore, the plan is to create a good std/data/bytes module that gives views on bytes where you can read/write int8/16/32/64 types but always to/from int's on the Koka side.

(see also What About the Integer Numbers?