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
I’m working on a project that simulates the bumbl example in the programming phoenix book. It acts almost like an email client. We have a...
New
Hi everyone,
I am toying with the idea of building a “match maker” for giving personal help to people that wants to start coding.
I sta...
New
Hello,
I know there is an approach for handling lists that allows for optimized traversal, but I can’t recall the specific method (somet...
New
Documentation
While reading the Scoped Routes section, I noticed that the documentation currently refers to a problem without explainin...
New
So my question is quite simple and i have found no conclusive answer on forum, google or AI.
Should we use :erlang.float for Integer to ...
New
I recently noticed that Elixir’s Logger defaults its primary log level to :debug when no :logger, :level application configuration is pre...
New
I’m new to elixir and just tried to install the elixirLS extension for VScode(ium) and it is throwing some errors that I would like help ...
New
Other Trending Topics
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
I am happy to introduce the very α version of the new programming language compiled to BEAM.
Welcome Cure.
It has literally three kille...
New
Hi there! We created Gust: A task orchestrator inspired by Airflow.
For those who have never heard about Aiflow, it’s a Python-based wor...
New
Hi everyone!
The first release candidate for the Expert language server project is now available!
We’ve published a press release detai...
New
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
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
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #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.