Isn’t the whole point of dynamic languages that they’re monotyped? They’re equivalent to a type system with only one type, any. Really, most dynamic languages are equivalent to having a single tagged union of all the different sorts of values in the language.
If you add additional types, you get into gradual type systems.
A language has dynamic types if the type-resolution is done at runtime. The other kind is static types, where it’s done at compile-time.
A language is monotyped if every value is compatible with every operation, so there’s actually no type resolution.
A language has explicit types if you declare your types, implicit ones if you can’t declare them, type derivation if declarations are optional but they exist and are static you declaring or not, or gradual types if declarations are optional but they exist and are dynamic you declaring them or not.
All of those things are different.
Also, some people will insist “types” can only be static. Go ask those people whatever is the name of the things Python have, because either they just invented some different words, or they are only trying to confuse you.
Bob Harper uses ‘unityped’ in his post about how dynamic typing is a static type system with a single type in disguise. I’ve literally never heard “monotyped” used as a term in a dynamic context.
In Types and Programming Languages, Ben Pierce says “Terms like ‘dynamically typed’ are arguably misnomers and should probably be replaced by ‘dynamically checked’, but the usage is standard”. Generally, you’ll see ‘tag’ used by type theorists to distinguish what dynamic languages are doing from what a static language considers a type.
Type systems have existed as a field in math for over a century and predate programming languages by decades. They do a slightly different sort of thing vs dynamic checking, and many type system features like generics or algebraic data types make sense in a static context but not in a dynamic one.
many type system features like generics or algebraic data types make sense in a static context but not in a dynamic one
Hum… Not so much. You can do polymorphism with dynamic types perfectly well, with mechanisms that are exactly equivalent to the ones used on static languages (python people just love that). You can also have tagged unions with a completely equivalent mechanism from algebraic data types (that everybody ends-up doing in json sooner or later). Also you can do out of order verifications in a logical fashion, rewrite code at run time, or anything else even. It’s compile-time that has limitations on what it can do, runtime has none.
I am not at all against inventing new names. But I am really against naming concepts that are not independent from each other. And insisting on those is just signaling-oriented pedantry. So you can very well insist that the dynamic thing is not called “type”, but you can’t really do it in a way that implies the only thing you can get out of them is a type mismatch error.
