josevalim
Type system updates: moving from research into development
I hereby officially announce the Elixir type system effort is transitioning from research into development. Read the full-announcement here: Type system updates: moving from research into development - The Elixir programming language
This new exciting development stage is sponsored by Fresha (they are hiring!), Starfish* (they are hiring!), and Dashbit.
Thank you!
First Post!
Eiji
I understand the first 2 milestones, but can somebody say what’s a difference between the @spec attribute and 3rd milestone? ![]()
The third milestone is to introduce the (most likely)
$-prefixed type annotations for functions, with no or very limited type reconstruction: users can annotate their code with types, but any untyped parameter will be assumed to be of thedynamic()type. If successful, then we will effectively have introduced a type system into the language.
Can’t Elixir compiler use already existing specs instead of adding yet another annotation? We have any() and term() which should be more than enough as replacement for dynamic(). ![]()
Also is adding a type system like in the post means replacing part or even all features of tools like dialyzer by Elixir compiler? If so I hope the compilation would not be longer because of creating plts … ![]()
Most Liked
josevalim
There are a few details I don’t appreciate about how we implemented typespecs (for example, I find them too verbose) but the deal breaker here is that typespecs are not capable of expressing the proposed type system, so we will need something new.
lifeofdan
I had to create an account here just to say how much I love this. This is incredibly exciting!
josevalim
The type system allows us to support any literal as type but it is still undecided if we want to do that. Opposite to the Dialyzer, an actual type system will be strict about the expected arguments. Imagine this code:
$ :foo or :bar -> string
def foo_or_bar(:foo), do: ...
def foo_or_bar(:bar), do: ...
Now imagine you call it like this:
foo_or_bar(String.to_existing_atom(string))
Because you are passing any atom to the function, the type system will warn about a type error. While Dialyzer would never warn. So you would need to write this instead:
case String.to_existing_atom(string) do
:foo -> foo_or_bar(:foo)
:bar -> foo_or_bar(:bar)
_ -> raise "expected foo or bar"
end
Therefore, more specific types will require you to prove that you are passing those specific types and that may actually make the type system more annoying than helpful.
Since there are trade-offs here, it is a decision we will make later once we have a better feeling for the type system.
Correct.
Last Post!
erszcz
This is quite a well-known wisdom in communities using languages with exhaustiveness checking. See Yaron Minsky’s talk “Effective ML” - he talks about catch-all patterns, exhaustiveness, and code evolution over time at 28 minutes into the video: Jane Street Blog - Effective ML video
BTW, this material is from 2010!
With a type checker a few more of the techniques he describes there would be possible in Elixir (or Erlang), or at least enforceable at compile time.
Popular in News
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex









