3 ms·

> Erlang VM, which is dynamically typed > x64 machine which is mostly untyped Dynamically typed and untyped are not the same, no?

by gnull 3y ago

gnull 3y ago
Also: x86 is very much statically typed. Your types are 8-, 16-, 32- and 64-bit words. Each machine instruction knows the exact types of its operands, so there's no overhead on determining the types of values at runtime (like you'd need to do in case of dynamic typing).
- JonChesterfield 3y ago
  It's a tangent but a good one. 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.
  - gnull 3y ago
    What is "untyped" exactly? Google tells me it's the same as "dynamically typed". 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.
JonChesterfield 3y ago
Spent so long trying to get quote formatting on a mobile that I didn't notice I've replied to the op, not the subthread. Bad times. 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.

> Erlang VM, which is dynamically typed > x64 machine which is mostly untyped Dynamically typed and untyped are not the same, no?

by gnull 3y ago

> Erlang VM, which is dynamically typed > x64 machine which is mostly untyped Dynamically typed and untyped are not the same, no?

gnull 3y ago

Also: x86 is very much statically typed. Your types are 8-, 16-, 32- and 64-bit words. Each machine instruction knows the exact types of its operands, so there's no overhead on determining the types of values at runtime (like you'd need to do in case of dynamic typing).

JonChesterfield 3y ago
It's a tangent but a good one. 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.
- gnull 3y ago
  What is "untyped" exactly? Google tells me it's the same as "dynamically typed". 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.

JonChesterfield 3y ago

Spent so long trying to get quote formatting on a mobile that I didn't notice I've replied to the op, not the subthread. Bad times. 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.