It's reinventing the good part of the JVM (the JIT and the bytecode), better than the JVM (unsigned ints and value types are supported), without the bad parts of the JVM on the Web (the libraries, including the slow graphics stack, etc.)
What do unsigned ints bring to the table? I'd use them in C to avoid undefined behaviour, but that's not a problem on the JVM. Value types sure, I guess, but they don't seem super important.
Can't we just make DOM bindings for the JVM and reuse the huge existing library base?
Without unsigned types you have to use the next larger type and mask. It's ugly, a pain, and slower. You run into this problem a lot when dealing with binary data.
You're begging the question, assuming you have to represent a particular unsigned type to start with. What's the problem that you're trying to solve?
I appreciate that e.g. particular image formats are defined in terms of unsigned integers of particular sizes, but parsing binary formats seems like a specialized use case that's not worth distorting the whole language over (and it already involves fiddling with endianness, so you can't directly use the "standard" version of a given-sized integer when parsing).
> parsing binary formats seems like a specialized use case that's not worth distorting the whole language over (and it already involves fiddling with endianness, so you can't directly use the "standard" version of a given-sized integer when parsing).
You call it "distorting the language", I call it "exposing the capabilities of every single CPU manufactured in the last 15 years".
> You're begging the question, assuming you have to represent a particular unsigned type to start with. What's the problem that you're trying to solve?
1. Compiling existing C++ codebases.
2. Multiplication and division are not identical for unsigned and signed values. Say I have a memory address on 32-bit (note that this applies equally well to 64-bit) and I'm doing pointer arithmetic. I'd better not be doing a signed multiply, or else values above 2GB will be corrupted!
> You call it "distorting the language", I call it "exposing the capabilities of every single CPU manufactured in the last 15 years".
There are plenty of CPU capabilities that languages don't exploit fully (e.g. most languages won't give you direct access to the carry flag) or only allow you to access via a specialized interface rather than making them a first-class part of the language (e.g. SIMD instructions). This seems entirely normal.
> Say I have a memory address on 32-bit (note that this applies equally well to 64-bit) and I'm doing pointer arithmetic. I'd better not be doing a signed multiply, or else values above 2GB will be corrupted!
I don't really see how this works (pointer arithmetic, not that one should be doing it at all, would generally involve adding or subtracting small offsets to pointers, I can't see any use case where you would want to multiply a pointer?), but in any case it doesn't apply equally well to 64-bit in any practical sense? If you happen to need an amount of memory between 2GB and 4GB or between 8EB and 16EB then maybe using unsigned pointers lets you use a smaller pointer, but that seems like a pretty narrow use case.
> There are plenty of CPU capabilities that languages don't exploit fully (e.g. most languages won't give you direct access to the carry flag)
Sure they do: the carry flag is the > operator.
> or only allow you to access via a specialized interface rather than making them a first-class part of the language (e.g. SIMD instructions). This seems entirely normal.
So if you want to argue that unsigned multiplication/division should be encoded as a magic intrinsic (as Java 8 does) instead of as a primitive operation, then I still think it's a bit silly to make such common operations require such verbose encodings, but I could be convinced either way.
> pointer arithmetic, not that one should be doing it at all
The point of wasm is to be a compilation target for languages like C and C++. So pointer arithmetic is very important here.
I don't think this is a "begging the question" fallacy. General purpose programming language often need to deal with binary data. This can be anything from documents, compressed files, images, audio, video, network data, a video framebuffer, and so on. Dealing with binary is in no way a "specialized use case" of programming; I'm honestly a little incredulous at your insinuation.
Further, this "distortion" amounts to adding 4 types and defining bitwise behavior, and since unsigned shifts are easier than signed shifts, no problem. I wouldn't call that a distortion, especially not compared to things like for-in and lambdas.
But really, can you explain your disdain for unsigned numbers? I've never heard someone argue for their exclusion from Java -- I thought we all accepted it was a mistake.
I view extra primitives as very expensive because they add a whole bunch of extra cases in the language itself; I like small languages where as much as possible can be moved into libraries. I just don't see the use cases for unsigned ints as being widespread enough to justify having them in the language; I've worked across a number of industries and I think I've seen them used once (when fixing a bug in ffmpeg), whereas for-in and lambda are used absolutely everywhere. I'm not especially anti-unsigned; if I was designing a JVM-like bytecode I'd remove short, and perhaps even (single-precision) float and int as well.
What's not to like? Why couldn't we just create a system compatible with Java bytecode, and just replace the APIs over which it interacts withthe system (as Android has done)?
That'd make it even possible to reuse old applets with just a tiny shim around them.
And it'd keep compatibility with a huge environment of libraries and languages.
What's not to like?