I’m starting a blog series detailing the design process I’ve taken towards introducing platform dependent types in Scala 3:
As you may or may not be aware, I’ve been working on a library called Slinc. I’ve managed a number of times to get some functionality working well, but something that’s always bugged me in it was the definition of platform dependent types. Platform dependent types are types that mirror C’s types in that their definition and how you work with them changes based on what architecture and operating system your program is running on.
This first blog post covers my initial attempts at creating these types and making them useable and user creatable. The series will go step by step through the design process and the many prototypes I iterated through until we reach the final result. I hope you all follow along with me as I go through these. The end result is quite interesting!
Platform-dependent types are one of the most confusing features of C, and one which leads to a very high likelihood of uncaught bugs when porting to platforms which don’t make the typical choices.
Witness, for instance, int32_t and such, which is what you want to see in pretty much any even remotely cross-platform C codebase, even though it’s an enormous pain to type instead of int or long.
The biggest challenge here is to make sure that Scala doesn’t just inherit the unmanageable error-prone mess that C has. If one wanted that, one ought to just code in C, and wrap that with an ABI once you want to get into Scala.
Indeed. That’s why I’m looking for an encoding of these types in Scala that allows the Scala compiler to help us instantiate these types. I believe I have the answer. I have an encoding I’ve done some experimenting with that works well and is relatively easy to use (at least so far for me )
However, I’ve got what appears to be around 4 more blogposts before I get to that answer . I just wrote up the second one and I’m proofreading it now.
)
. I just wrote up the second one and I’m proofreading it now.