> Erlang VM, which is dynamically typed
> x64 machine which is mostly untyped
Dynamically typed and untyped are not the same, no?
> x64 machine which is mostly untyped
Dynamically typed and untyped are not the same, no?
Machine code, at least x64/aarch64/amdgpu and the like, cannot be considered statically typed.
1/ there is no static checker
2/ if there was, the interpreter would run the failing code anyway
3/ memory can be integers, floats, machine instructions all at the same time
4/ registers overlap, e.g. writing to a 'i32' probably zeros the adjacent 32 bits in the same register
5/ instructions on the same register sometimes refer to floats and sometimes to integers
It also isn't dynamically typed, though a kernel might kill the program or hardware crash on some operations.
I think it's most usefully considered untyped in that there's no ahead of time verification and there's no runtime checking either.
Remember the context. The thread started with Elang VM making it impossible to make code faster, due to the need to accommodate Erlang's dynamic typing features and do runtime checks for that. Top comment said that dynamic typing per se can't be the obstacle for programs being faster, and gave x86 as an example of a presumably dynamic VM which does not limit the speed of the programs.
So "dynamically typed" from the article here meant that there's some runtime checks you can't unsubscribe from, and due to them there's a cap on how much faster you can make your code. It applies to some extent to x86, there's also checks there like segfault for example, and maybe you could save some space on silicon if you removed them and required the machine code to be verified to never cause segfaults. But I argue that this is too much of a stretch. Runtime checks that x86 performs are negligibly simple, and x86 is not a valid counter-example for the article's point. In my view the article's point is valid.
> 1/ there is no static checker
"return 0" is the static checker for x86 machine code.
But seriously: this is not a necessary condition for something to be statically typed, it can't be.
> 2/ if there was, the interpreter would run the failing code anyway
Failing code does not exist. All code is valid.
Haskell is undoubtedly statically typed. But division by zero will still cause a runtime error.
> 3/ memory can be integers, floats, machine instructions all at the same time
Ok. Disregard what I said about machine words. The only datatype in x86 is byte. Some operations use 2 bytes, some use 4. They may interpret them differently (some may see an int, some float), but it changes nothing, since both int and float operations are operations on bytes.
Whether x64 is typed or untyped feels like the start of an argument about whether xmm registers have the same type as stack memory which is kind of interesting but orthogonal to elixer.
I would agree that static, dynamic and untyped are distinct things. You can compile from a source language with any type system to a target language with any type system. I think, there may be edge cases around excessively constrained languages.
As an extreme example, the target machine says nothing about whether you can constant fold 1+2 into 3 in the source language, but the source language can definitely block or enable that minimal optimisation.