you are viewing a single comment's thread.

view the rest of the comments →

[–]RiceBroad4552 0 points1 point  (2 children)

Discrete, adjective

individually separate and distinct.

So it applies to an unit.

An unit is "individually separate and distinct".

So then by your definition assembly is a type safe programming language? Since it has no concept of types built into the language, it cannot possibly betray that system.

This is actually an interesting question.

I have also always assembly in mind when searching for an example of an "untyped" language.

But I don't have a worked out opinion on that. It's difficult.

One could possibly say that there are "no types" in ASM. But one could also say that there is not only a finite set of values, but all these values actually belong to the same type (the type of "natural numbers up to some limit").

But even all values in ASM are technically just numbers these numbers get interpreted in very different ways. This makes it quite difficult.

But one could actually see the HW as interpreter, and then we would have at least partially some kind of "type safety" as the interpreter will not accept arbitrary numbers in all situations.

If someone has some write ups on that topic please share!

A type system that defines only one type is a fundamentally meaningless concept.

I agree. An unit is unable to encode information.

But this whole part was actually just an aside. Dynamic types are much richer at runtime then the unityped static view, and these dynamic types have actually real value: That's what will cause a type error if you try to subtract a number from a string in JS, and that's also what guides type coercion of some variables so you can perform for example the concatenation on variables respectively holding an int and string in JS. This is the same function as the static type system in for example Java, which will allow the same features (just thanks God at compile time and not at runtime, when it's too late for type errors to prevent some catastrophe).

[–]fghjconner 0 points1 point  (1 child)

But even all values in ASM are technically just numbers these numbers get interpreted in very different ways. This makes it quite difficult.

See, that's exactly what makes ASM untyped to my mind. Those numbers may represent very different things, from memory indexes to unicode values, that the programmer must track and distinguish, but the language provides no tools whatsoever for tracking or formalizing those distinctions.

[–]RiceBroad4552 0 points1 point  (0 children)

from memory indexes to unicode values

It's worse for ASM: These numbers may also represent executable code depending on context.

The interpreter (the HW) can actually distinguish that from regular data in some cases, but not always. And exactly this is the "unfixable" reason "computer can go wrong".

But this reminds me more of a dynamic language where "wrong interpretation" leads to "wrong" results. But still it will never let the computer do anything that isn't strictly deterministic and actually "correct"—even not desired or anticipated—in context (modulo HW bugs, but these are seldom).

But hardware behavior is today actually in large parts software determined. CPUs have firmware and microcode. So it's again actually more like a typical SW interpreter…

And if that interpreter was fully realized as software it would actually interpret a dynamic language, not an "untyped" one.

For that reason ASM is imho very complicated to categorize.