-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dependent Types #366
Comments
Can you explain this using an example? I have no idea what "value-defined types" are, not "dependent types". |
Dependent types in this content refers to a type system similar to that seen in Coq, Agda, and Idris. The example referenced in #358 is that of the product type.
The problem here is the variable number of arguments. (what I referred to as a n-vector). def product(*args :Tuple[n]) -> Iterator[Tuple[n]]: pass where n is the length of the Tuple and the type of the k th element is Tuple[n, k] Dependent types solves this and more by generally allowing the value of the type to be part of the type signature. The value for the product example would include the length n of *args. The common example (which can be shoehorned into non-dependent type systems, but is still a good example) is disallowing 0 in the division function. |
My impression is that full dependent types are currently only good for pretty specialized applications (mostly research)... and even then they can be very difficult to work with. However, there might be some ideas that could be used in a more mainstream context. Retrofitting existing code (esp. imperative) with dependent types is still an open research problem, I think. |
Yes, the motivation of the proposal is less to say "lets just implement dependent types" and more "Is there anything we can get out of a simple approximation of dependent types". By "approximation of dependent types", I mean supporting many common features in one way or another. For example: Ignoring unpacking using * and *, the number of arguments is known before runtime. |
Closing this now, as there hasn't been any updates in a long time. If somebody has a more concrete proposal, feel free to open a new issue. |
This issue comes up on google search for mypy dependent types, so I want to link it to #3062 where this discussion continues. |
While trying to model the output of product from itertools #358, its become apparent that the mypy type system lacks the strength to model value defined types.
This will happen with any kind of n-vector and is and could be potentially solved statically using dependent types.
This would likely be a massive endeavor, but the conversation is likely worth having.
The text was updated successfully, but these errors were encountered: