Fl4m3Ph03n1x
Background
I am now trying Gradual type checking, as a consequence I am giving a shot to Gradient. As I see it, this is an alternative to Dialyzer.
Problems
So, on my first ever code snippet, I started with a pure function:
defmodule TipCalculator do
@spec getTipPercentage(List[String.t()]) :: non_neg_integer
def getTipPercentage(names) do
names_size = length(names)
cond do
names_size > 5 -> 20
names_size > 0 -> 10
true -> 0
end
end
end
From my point of view, my type checks are rather solid.
However, Gradient seems to have a different opinion:
===> Analyzing applications...
===> Compiling gradualizer
src/gradualizer.erl:45:2: Warning: opaque type top() is underspecified and therefore meaningless
src/typechecker.erl:3234:1: Warning: function type_check_cons_in/4 is unused
src/typechecker.erl:3247:1: Warning: function type_check_cons_union/4 is unused
src/typechecker.erl:4612:1: Warning: function verbose/3 is unused
src/typechecker.erl:4870:1: Warning: function gen_partition/3 is unused
src/typechecker.erl:4872:1: Warning: function paux/3 is unused
==> gradient
Compiling 14 files (.ex)
Generated gradient app
==> grokking_fp
Compiling 1 file (.ex)
warning: code block contains unused literal "\n" (remove the literal or assign it to _ to avoid warnings)
lib/tip_calculator.ex: TipCalculator
Generated grokking_fp app
Typechecking files...
lib/tip_calculator.ex: Undefined remote type Access:get/2 on line 0
From what I can understand, this one piece of code (from a fresh project) has several issues:
- warning: code block contains unused literal “\n” (remove the literal or assign it to _ to avoid warnings)
- lib/tip_calculator.ex: Undefined remote type Access:get/2 on line 0
The fist one sounds like a warning credo (or a linter) would give me. So I am not really sure what do do with it. I am expecting a tool that does type checks only (maybe I am wrong?).
The second one, I have no idea.
Questions
What am I doing wrong?
Trending in Questions
Hello!
Suppose you are building workflow (order / task / payment) processing system with the following requirements:
Each workflow con...
New
I’m aware of 2 such projects, are there others?
git: GitHub - team-alembic/realworld: A fullstack Phoenix LiveView application with back...
New
Hi all,
I’m working on a Phoenix project where I need to make external HTTP requests and I’m trying to choose between Req and HTTPoison....
New
Hi everyone.
My team and I have been working on a fairly modest app based around video streaming and chat, but we’ve landed a customer t...
New
Hi,
we run different LLM models across a cluster, with each node loading a configurable subset. Model-specific queues let nodes consume ...
New
Hi all, I’m new here and would like to hear peoples views on my Elixir/Phoenix based game-engine! :smiley:
Mutonex gamedesign was finish...
New
Hello
I’ve been coding in Elixir for almost two years now because of my current job where we implemented Elixir in our application. But ...
New
Other Trending Topics
Hey there,
I haven’t seen a list of useful Elixir specific skills for the popular AI tools yet so I’m starting one here with my first.
...
New
I fully migrated to my own harness from Anthropic/Gemini and I think it’s time to share it. Welcome DSH, the DeepSeek Harness, fully writ...
New
Hey. Is there anyone here who creates agents in their apps? Not talking about using agents, but creating them. I’m finding it pretty diff...
New
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself.
My main conc...
New
(I just needed to vent somewhere and LinkedIn is full of hope, or hype, I’m not sure which exactly)
AI dream has many faces, but general...
New
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
- #ai
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #blog-post
- #ecto-query
- #elixirconf-us
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #hex










Showing Posts 1 to 4- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
Nicd
This looks suspect for me. Looks like Python type annotations. What you want in Elixir typespecs is
[String.t()]. I thinklist(String.t())may work as well.Worth noting that your first warning is coming at compile time, so probably not from Gradient at all.
Fl4m3Ph03n1x
You are correct. I got confused a little bit, the correct typing was
[String.t].I will say however that:
Is not (to me) a very descriptive error message.
However, given the alternative (dialzyer) message is not much better:
I will say however, the line number was an incredible help to find the issue.
With Gradient
line 0really threw me off.Nicd
I think the error message is that because
x[y]is translated by the compiler to anAccess.get(x, y)call and that’s what is then seen by the tools: a typeAccess.get/2with two arguments. It rightly complains that such a type is not defined. Don’t know why Gradient loses the line information, though.Fl4m3Ph03n1x
I have created an issue in the tool’s repository:
Let’s see what the author’s opinion on the issue is.