3 ms·
> If you occupy any space on the spectrum besides fully static typing, you must represent and check your types at runtime. If the language requires you to give
by Someone 4y ago
> If you occupy any space on the spectrum besides fully static typing, you must represent and check your types at runtime.
If the language requires you to give at so much type information that the compiler can infer all the types, I would say that language, from the compiler’s view, would have fully static typing, so it wouldn’t have to do any checks at runtime, but from the programmer’s viewpoint, it could look as if it didn’t have fully static typing.
The modern auto to deduce a type in C++ makes a small step towards that, but I think it could be taken further. The language could deduce types both in the direction “if you pass foo to a function taking an integer, it must be an integer” and “if you only pass integers to bar, bar must take integers”.
I expect it will be hard to specify a powerful algorithm for filling in the blanks that feels natural to programmers, though. If the compiler frequently complains about missing type information where the programmer doesn’t understand why it complains, the language won’t be popular.
- lolinder 4y agoWhat you're describing is already common in functional languages such as OCaml and Haskell. They tend to use the Hindley-Milner type system, which allows for exactly the kind of non-local inference you're talking about (where `auto` is only for local inference): https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_sy... However, better type inference does not mean that a language is no longer statically typed, it just moves a lot of the burden of assigning types from the programmer to the compiler. You still don't have as much flexibility at runtime, and you still can't run your code until the compiler can prove that it it correctly typed. The only thing you get is less syntax, not dynamic semantics.
- munificent 4y ago> I expect it will be hard to specify a powerful algorithm for filling in the blanks that feels natural to programmers, though. If the compiler frequently complains about missing type information where the programmer doesn’t understand why it complains, the language won’t be popular. This is the problem in a nutshell. Folks in the optional typing and gradual typing communities have been trying to pull this off for decades and so far no one has been able to come up with a language that: 1. Lets you ignore types completely and write dynamically typed code in some parts of the program. 2. Gives you the expected performance of completely typed code in parts of the program that are typed. 3. Is sufficiently pleasant to use that it gets adoption. There are languages that give you either 1 or 2 along with 3. There may be some language out there that gives you 1 and 2 but if so, it doesn't give you 3 or I would have heard of it. I suspect it's intractable.
- kaba0 4y agoThat has been done by Haskell for example for decades. Look into Hindley-Milner type systems.