We need a bytes module for better working with file and network I/O.
See issue 388 for a discussion about unsigned integer values and the fact that Daan wants a bytes module to work at a bytes level for low level representations.
Quote from his comment there:
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.
Ideally we would have not only have operations for reading / writing values into a byte buffer, but also a bytes iterator or byte slice that could read/write & advance using different methods like read-int32, read-float32, etc.
We need a bytes module for better working with file and network I/O.
See issue 388 for a discussion about unsigned integer values and the fact that Daan wants a bytes module to work at a bytes level for low level representations.
Quote from his comment there:
Related: (libuv: issue #341) (libuv: PR: #384)
Ideally we would have not only have operations for reading / writing values into a byte buffer, but also a bytes iterator or byte slice that could read/write & advance using different methods like
read-int32,read-float32, etc.