bartblast
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
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
At WyeWorks, we believe great software is built by combining technical excellence with genuine human connection
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #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.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
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?