0..65535 is a valid spec. But what you described applies as much to float() or String.t().
It’s also not just the elixir team working in the space. There’s also various ongoing efforts for adding type systems on erlang.
LostKobrakai
0
D4no0
The question is, does it work as expected? The last time I had to use either ftp or sftp library from OTP, when I introduced a wrong port range I got no warnings and a strange match error.
Then it must be some core reason why a custom elixir implementation was needed? I don’t remember those other tools trying to make intersection types.
0
LostKobrakai
All of them are working a the problem from different angles and therefore different tradeoffs.
Probably not, but that’s due to the range being too large and dialyzer will simplify data aggressively.
________________________________________________________________________________
lib/test.ex:8:call
The function call will not succeed.
A.test(101)
breaks the contract
(0..5) :: 0..5
________________________________________________________________________________
0..100 is then already simplified and the violation no longer detected.
1
arcanemachine
Typescript (and its dev tooling) are my main example of why static typing is something to look forward to.
Right now, I can only dream of having the beautiful DX afforded by tsserver. But the dream is getting closer…
5
yordisprieto
My primary concern revolves around developer experience (DX), rather than technical aspects. Although I acknowledge this issue might stem from the broader ecosystem, I believe it’s crucial to consider the overall impact.
The core of my apprehension lies in the dependency on tools, particularly those that don’t automatically rectify lint/formatting rules. This reliance often leads to divergent approaches among developers: some strictly adhere to tools like linters, others dismiss them, and then there are those who, like myself, are willing to use these tools provided they resolve issues efficiently.
My stance is neutral as long as the tools effectively handle the underlying problems. However, I foresee that introducing @spec-like annotations could perpetuate existing frustrations in several ways:
-
Ordering: The placement of
$in relation to other annotations like@docor@decorateor any other notation is ambiguous. Should it precede or follow these annotations? The lack of a clear convention can lead to inconsistencies and bikeshedding. -
Collocation: When dealing with multiple function patterns, the placement of these annotations becomes a challenge. Should they be grouped at the top or positioned close to the relevant function definition?
-
Naming: The requirement (or lack thereof) for naming parameters in type signatures needs clarification. Ensuring consistency between the type signature and the actual function parameters can be cumbersome if not handled well.
-
Documentation Colocation: Unlike TypeScript, where type annotations within documentation are unnecessary, the proposed system raises questions about the documentation of argument types. Ensuring that documentation is both concise and informative is key. Today we rely on discipline alone and packages such as
NimbleOptionsbut this could be improve a ton! -
Language Server Protocol (LSP) Integration: It’s crucial to consider how new notations will interact with tools like LSP. Ensuring that these tools take on most of the workload is essential for a smooth developer experience. How refactoring will work, and if the AST will allow the tools to their job affectively.
1
stevensonmt
josevalim
Creator of Elixir
We have been considering these aspects for sure, but it is too early to focus on them in general, given we are still working on the semantics of the type system.
We have discussed this a couple times, so I am not going to rehash all points again, but there is already too much that can happen in function clauses and we don’t want to add more. I bet no one want to see this code:
def foo({_, _} = bar \\ {:foo, :bar} :: {atom(), atom()}) :: integer()
Furthermore, a function specification and its implementation are two separate things. In Typescript, you can’t have multiple clauses (afaik). In Elixir, if we tie the specification to the clauses, there is a chance you will accidentally change the specification when moving clauses around and when refactoring code, and by doing so you will get in the way of the type system.
At this moment, I’d say we should put signatures after the docs and grouped immediately before the first clause, since they help both with the documentation and code. And I want them grouped because I want a unified view of how my function behaves and not scattered across multiple lines.
But maybe I will change my mind in 6 months or in 2 years. In order to figure out the best approach, we will need to try and explore things. It hasn’t been a week since the compiler got a rudimentary understanding of types and type signatures certainly won’t happen this year.
Now it is definitely too early. All we are asking for is patience, patience with our work, and patience between yourselves. Let’s not rush this. The worst we can do is to standardize into something sub-optimal because we were too quick to settle.
18
josevalim
Creator of Elixir
As far as I know, handling of intergers (and intervals) has been solved for quite some time. The issue though is that, the more specific the types are, the more you will have to prove to the type system.
Imagine you write this code:
port = trunc(:rand.uniform() * 1000 + 3000)
listen_on_port(port)
This code will guarantee to give you a port between 3000..4000. But for the type checker to understand this is actually quite complex. So you either buy in into a lot of complexity (and most likely performance) or you handle fewer cases. And, if you don’t handle all cases (which you cannot), in some situations you will be forced to “prove it” by writing something like this:
port = trunc(:rand.uniform() * 1000 + 3000)
if port not in 3000..4000 do
raise "bad port"
end
listen_on_port(port)
Which is completely redundant but, without it, you get typing violations.
Set-theoretic types can be quite expressive, allowing you to even express types akin to regular expressions, but all of them come with similar drawbacks.
For these reasons, we have not yet decided if we want “fine-grained integers” into the language. We will definitely have that for atoms and we might introduce more granularity later on, but it definitely has trade-offs.
7
hubertlepicki
I assume you did the research, and can save me hours of googling - is there a dynamically typed programming language that does this well? i.e. the language is gradually typed?
0
josevalim
Creator of Elixir
It really depends on what you mean by “this” and “well”, as I am pretty sure we have not found something that does everything well (and according to everyone’s definition of well). There is also a question of how well the lessons from other languages (such as JavaScript, which is OO and highly polymorphic) maps to Elixir (functional and conservatively polymorphic).
I recommend watching my ElixirConf US 2023 keynote, which talks about the principles and how we are tackling some ideas in ways not done before. After all, we need to find a solution that works well for Elixir. 
3