New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add basic unsigned int32 and int64 support #7280
Comments
Comment author: @gasche To understand the issue better I looked at how I think if we wanted good support for unsigned integers in the language adding abstract uint{32,64} types would be a good solution -- implemented as custom types with their own comparison/serialization, and their own compiler primitives. |
Comment author: @hcarty That's fine too. There was a mailing list post that I can't find now which lead me to believe that separate unsigned types/modules wouldn't be welcome. If we can have fully separate types then that should make them simpler for users to find and understand too. |
Comment author: @alainfrisch It seems really bad to mix signed and unsigned ints of the same size in a single type. I'm not aware of any high-level language that does that. So unsigned ints would be new built-in types; they need to be built-in because the optimizer needs to know about them, at least to support local unboxing and constant folding. We'd also need to provide operations such as "/" and "mod", and I guess this would impact the runtime system (primitives) and/or the various backends. So this is really not a "pure stdlib" proposal. How common is the need for unboxed int types? Can you provide some typical usage scenarios?
Can you elaborate on that part? I guess that in both cases (stdlib or external), there would be a need for new C primitives. |
Comment author: @hcarty Here is the post: http://caml.inria.fr/pub/ml-archives/caml-list/2004/07/f1c483068cc62075c916f7ad7d640ce0.fr.html, and a related Stack Overflow response: http://stackoverflow.com/a/12181662 - those are why the initial request is/was for additional operations on the existing types. If separate types and operations are an option then, again, that seems like a better solution. As far as external libraries, the biggest issues are optimization (can a user-defined integer type ever be as efficient as one that is built in?) and bigarray support. I've run into both, primarily when working with serialization formats which assume the presence of unsigned integers. |
Comment author: @paurkedal I think int63 and uint63 types would also be useful, considering that they are unboxed on 64 bit targets, while int on 32 bit targets may be too small for some applications. |
Original bug ID: 7280
Reporter: @hcarty
Status: acknowledged (set by @damiendoligez on 2017-04-14T14:38:49Z)
Resolution: open
Priority: normal
Severity: feature
Category: standard library
Has duplicate: #4908
Monitored by: @hannesm braibant @diml @ygrek @yallop @hcarty
Bug description
It would be nice to have the following functions available in the stdlib as they are not easy to add externally:
Int32.compare_unsigned
Int32.unsigned_to_int
Int32.unsigned_of_int
Int32.unsigned_of_string
Int32.unsigned_to_string
Int64.compare_unsigned
Int64.unsigned_to_int
Int64.unsigned_of_int
Int64.of_unsigned_int32
Int64.to_unsigned_int32
Int64.unsigned_of_string
Int64.unsigned_to_string
Or possibly their equivalents in Int(32|64).Unsigned modules.
The text was updated successfully, but these errors were encountered: