Qqwy

Qqwy

TypeCheck Core Team

Hi everyone!

I recently had an idea. This is by no means a revolutionary concep, and other people probably have thought about it before (but maybe not in the context of Elixir), but I think it might be a useful one.

I have not gotten around to (attempt to) implement it yet. I do think it is possible (and of ‘average’ implementation difficulty. Not trivial, but not ridiculously hard either), but I would like to give the community the opportunity to shoot holes in the idea, as well as gauge if I am the only one excited about this, or if other people would like to use it as well.

Total Case Statements

It is very frequent that we pattern-match in a case-statement or function-head on the different possibilities a value might take. Of course, since Elixir is a dynamically/unityped language, a value might be ‘anything’ at any given time, but usually we expect only one of a small subset of these values, especially when we are using a(n approximation of a) sum type. Examples of those are for instance:

  • true | false,
  • [] | [head | tail]
  • :lt | :gt | :eq
  • {:ok, value} | {:error, problem}-tuples,
  • Ecto.action() :: nil | :insert | :update | :delete | :replace | :ignore
  • The atom-names of the fields in your struct.
    etc.

Now, it would be nice if we can somehow indicate that there is a case-statement where we expect such a sum type, and we want to make sure that we have cases for all possible values of that type. In a statically-typed language, this is usually built-in. In a dynamic language, it is not. But if we indicate to the case-statement the typespec that we want to handle, then it could be able to check if we have implemented clauses for each of the inhabitants of the type.

So I propose a macro, with a signature like e.g. total_case typespec, value do ... end, which could be implemented in a library, which would:

  1. Check, at compile-time, if the different match-handlers in the block together cover all possibilities of the type that is passed in.
  2. Maybe (if possible and not ridiculously hard to implement) warn about clauses that prevent later clauses from ever matching.
  3. After this check, compile down to a simple case value do ... end.

Sounds this useful to anyone?
The main thing that I don’t know about currently (besides having not enough spare time to start working on this right away) is how easy it is to programmatically interpret typespecs at compile-time.
It might also be possible that Dialyzer/Dialyxir already does some case-checking; this is something I don’t know, since until today I have struggled to set up + configure Dialyzer properly for my code. But even then I think that having a macro that would enforce this behaviour once set up would make a lot of sense over/alongside using an opt-in typechecker.

What do you think?

Showing Posts 1 to 3

lpil

lpil

Creator of Gleam

I think this would be fantastically useful and I previously started work on such a macro before getting distracted by Gleam.

You can see the API I was working with here → sum/lib/sum.ex at master · lpil/sum · GitHub

If you build it I certainly would use this :slight_smile:

LostKobrakai

LostKobrakai

Isn‘t a function with many heads essentially a case statement, which you can typespec?

OvermindDL1

OvermindDL1

Yep, but it’s also not ‘total’, meaning that if something new is added elsewhere it may (often won’t) catch it and tell you to add a case for it.

— All posts loaded —

Where Next? Top

Trending in Discussions Top

AstonJ
As the title says, please share what you’ve been up to with Elixir. Whether that’s been learning it, looking into it, making stuff with i...
2977 94592 917
New
cblavier
Hey there, It’s been more than a year since we started using LiveView as our main UI library and building a whole library of UI componen...
New
mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
heathen
Quite interesting article Google brought me. Didn’t find any mentions about it here. What do you think in general? Would you use togethe...
New
mhanberg
Hi everyone! The first release candidate for the Expert language server project is now available! We’ve published a press release detai...
New
AstonJ
Since we have deprecated our Erlang sections (as we have dedicated Erlang Forums now) let’s add this thread for those who’d like to post ...
New
Null-logic-0
What IDE or editor are you using for Elixir development? Personally, I use Zed, and I really like it, but sometimes I wish there were a ...
New

Other Trending Topics Top

JesseHerrick
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
marciok
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
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Dmk
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
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
webofbits
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself. My main conc...
#ai
New

Latest on Elixir Forum

Elixir Forum

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews