bartblast
Typing violation warning when comparing atoms
Why comparing atoms gives typing violation warning?
consider:
defmodule MyModule do
def test do
:a < :b
end
end
mix compile my_module.ex
gives a warning:
Compiling 1 file (.ex)
warning: comparison between incompatible types found:
:a < :b
While Elixir can compare across all types, you are comparing across types which are always distinct, and the result is either always true or always false
typing violation found at:
│
3 │ :a < :b
│ ~
│
└─ my_module.ex:3:8: MyModule.test/0
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Producing high quality Elixir screencasts since 2017.
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
- #elixirconf-us
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
First 10 of 13 Posts!
tcoopman
What’s the result you expected? What are you trying to do?
antoine-duchenet
Because
:aand:bare not considered to be of typeatom()but respectively as type:aand:b.LostKobrakai
And as mentioned in the warning the result of the comparison is static as well.
bartblast
Since the
<operator is inlined with:erlang.</2, I expected the compiler to resolve its typing to a parametric polymorphic definition, something akin to(a, a) -> boolean() when a: term(). I didn’t expect singleton types.I gave a simplified example to illustrate the problem, which I encountered when implementing client-server consistency tests in Hologram. Basically, I test whether manually transpiled Erlang functions behave exactly the same as their server counterparts.
LostKobrakai
If the typesystem has distinct types, why would it fall back to less specific types? This would be different if you would have variables here, but you hardcoded values for the comparison.
bartblast
@antoine-duchenet @LostKobrakai Guys, considering your previous answers, does this mean that Erlang functions are not treated as “atomic” functions for the type system and they don’t have hardcoded typings? Or maybe the underlying Erlang functions’ abstract code (or bytecode) is analysed as well in the process to determine the typings?
LostKobrakai
Not sure I get what you’re asking for, but I don’t think there’s much to it.
With 1.17 warnings where implemented to warn when comparisons are made between different types of data – mostly to warn for the common footgun of comparing structs like
DateTime, which would use structural comparison not semantic one. That’s the source of the warning.The reason for getting the warning if both sides are atoms comes from the fact that the new typesystem implementation considers atom() a divisable type, which includes all possible individual atoms. So
:aand:bare distinct types based on the typesystem, but both are part ofatom(). The wording sounds a bit unfortunate here though given it’s a bit ambiguous what type of “type” the error refers to.dimitarvp
He’s probably asking about BIFs and such.
LostKobrakai
BIFs are a runtime/implementation concern though. The compiler (and the typesystem) generally don’t care about any of that.
dimitarvp
So your functions that call them would never be type-checked by Dialyzer whether they pass the right types of arguments to BIFs, is that what you’re saying?
Last Post!
sabiwara
I’m not sure if I understand your question correctly, but functions applications (
Foo.bar(baz)or:foo.bar(baz)) are not typed yet, this will come with future releases.Standard library functions from Elixir and Erlang will be typed then.