This module doesn't seem to make it possible to type-annotate map and filter, which are Python builtins.
I believe that dynamic typing results from frustration over generics, rather than over static typing in general. (Type stuttering is another problem, but modern languages solve it with local type inference.) I mean, annotating non-generic functions is always straightforward doesn't introduce much complexity:
# s should be str
# returns nothing
def print(s):
...
# just becomes (using Py3 annotation syntax)
def print(s: str) -> None:
...
However, it's much harder to write a type annotation of generic functions. Worse, remember that Python's map is variadic.
# for any types t0, t1, t2, ... tn:
# fn is a function that takes arguments of types t0, t1, ... t(n-1)
# and returns a value of type tn;
# seqs are iterables of types t0, t1, ... t(n-1);
# returns a list of type tn.
def map(fn, *seqs):
...
# How to write this signature is non-obvious
Many mature static typing systems would allow you to express such types (usually called parameterized types). But any one of them would require more than those trivial notations in print.
That's when the dynamic typing people get annoyed and go "fxxk static typing systems, I can handle this in my mind". Which is about 65% (totally random estimation) the point of dynamic typing in my opinion.
Any type checker for dynamic typed languages that doesn't seriously try to solve the generics problem is not genuinely interesting.
Even that trivial `print` annotation breaks duck-typing; the print function can actually accept anything that responds to `__str__`.
Similarly, is there any reason the example `add` function in the OP shouldn't be able to add strings, or lists?
I've seen a lot of these quick-runtime-type-checking libraries, but they always have the same problem as manual type-checking: they make the constraints much stricter than they need to be and prevent entire classes of useful behavior.
I think `abc` would be overkill for this. My understanding is that you might use that to add behavior to a bunch of classes that aren't related hiearchically. But for type safety, all you need to do is check for the single magic method.
You can use it for that, but you can also use it to check for rough interfaces. (The classes are rigged to fool isinstance() via dark magic.) It's fairly common that you want more than one magic method, but don't care too much what the type is as long as it's sorta like a `list` — thus, MutableMapping.
There is nothing special about map and filter, they are not idiomatic Python because there are better ways to do the same things.
Python 3 annotations are already not used in any specific predetermined way, so if you create a system to do something with type annotations then you can implement List(str) or whatever it is you want an annotation to work like.
> There is nothing special about map and filter, they are not idiomatic Python because there are better ways to do the same things.
True, list comprehension is often used instead. But a complete typing system should be able to type-check that too. The point is not changed.
Also, I only used map and filter as an example. Python programmers tend to write a lot of generics functions without actually knowing it.
def f(g, *args):
...
r = g(*args)
...
return r
This function is actually quite generic, akin to map.
And we are not yet getting into the realm of "trait" or "concept" or "typeclass" or whatever.
def sum(*nums):
s = 0
for n in nums:
s += n
return s
Remember, although s is definitely an int, s + n may yield some completely unrelated type if n implements __radd__. The function here involves potentially infinite number of types, and their __add__ or __radd__ traits (reusing the name of the Python magic method). To fully express its type without unnecessary constraints is an interesting exercise. Since Python allows dynamic parameter list building (like sum(*nums)), dependent typing may be necessary for that purpose.
Are there languages that include the strong type checking, inference, and typeclass functionality of Haskell while also being a little more forgiving in terms of purity, so that writing ordinary programs is not quite so troublesome as in Haskell?
Rust has a decent amount of type inference, traits and strong guarantees.
Ocaml/SML are both functional languages similar to haskell, and allow IO pretty much anywhere. They don't have typeclasses, (although ML people would say there's nothing you can't do with the ML module system[0]).
You have a strange definition of interesting. Even dynamically typed languages are used in a static way most of the time; this is why JavaScript engines can perform well on most code. A type system without generics can still find plenty of bugs.
I'd agree with his definition and your point simultaneously. Type system with only 0-th order types are still useful for optimization and error capture, but higher order structures and higher order polymorphism are both incredibly useful and more powerful than 0-th order types.
It's not hard to imagine an extension to ML-style types that could cover variadicity:
map : ('a... -> 'b) -> ('a list)... -> 'b list
Where <type>... denotes <type1> -> <type2> -> ... -> <typeN> spliced into the type signature, with each type variable 'a in <type> replaced with 'a1, 'a2, ... 'aN. You could cover tuples too:
zip : ('a list)... -> 'a,,, list
Bit ugly, and writing a type checker for it could be fun, but it seems workable.
Fully typing variadicity in Python is only possible with dependent typing, since Python allows you to build the argument list dynamically. Generally speaking you can't even determine the number of arguments statically:
args = []
while some_condition():
args.append('x')
f(*args)
Typed Racket allows you type some common cases, though.
I believe that dynamic typing results from frustration over generics, rather than over static typing in general. (Type stuttering is another problem, but modern languages solve it with local type inference.) I mean, annotating non-generic functions is always straightforward doesn't introduce much complexity:
However, it's much harder to write a type annotation of generic functions. Worse, remember that Python's map is variadic. Many mature static typing systems would allow you to express such types (usually called parameterized types). But any one of them would require more than those trivial notations in print.That's when the dynamic typing people get annoyed and go "fxxk static typing systems, I can handle this in my mind". Which is about 65% (totally random estimation) the point of dynamic typing in my opinion.
Any type checker for dynamic typed languages that doesn't seriously try to solve the generics problem is not genuinely interesting.