Opinions wanted: A superset of regular Erlang for type checking and deduction

[Dmytro Lytovchenko]

Collecting public opinions on the idea.
The project stage is: investigation and some experiments.

The idea is to create a translator tool, a layer above the standard OTP
`erlc`, similar to what TypeScript does for Javascript. With TypeScript you
take .js files, rename to .ts to redirect to a different compiler and it
became a perfectly valid TypeScript source. Then you're free to spec some
variables and arguments, as you need.

*Description*

- A translator for a superset of Erlang syntax:
- The tool will replace erlc by providing identical command line
interface.
- The tool will read Erlang source passed with erlc command line.
- The tool will PREPROCESS → PARSE → TYPECHECK & DEDUCT
- The tool will output Erlang syntax then pipe to erlc.
- Possibly the output source will be modified (dynamic checks
injection etc)
- Example could be:
- original code: myfun(A, B) -> {ok, A, B}.
- augmented code: myfun(A: int, B) -> {ok, A, B}. % pinning type int
for A, but leaving B free for deduction


- Experimenting with Hindley-Milner type inference and whether it
matches Erlang programming model, and whether it can be made to work
without breaking existing code and instead to allow building on existing
regular Erlang syntax.


- *Might need pointers and advice right here*, I do not know what I am
doing and you're wasting your time reading this.

*Similar Tools*

- Similar to: otp/Dialyzer, but is not an external tool.
- Similar to: josefs/Gradualizer, but is not an external tool
- Similar to: WhatsApp/erlt
- Similar to: abstractMachinesLab/caramel, also outputs Erlang, but is
not a new language
- Similar to: https://gleam.run/, also outputs Erlang, but is not a new
language

There is no desire to rewrite erlc (lib/compiler), erlt, Dialyzer or
Gradualizer or create an entire new language, but some functions may
overlap.

*Main Goals and Priorities*

- Prioritize easy usage for existing regular Erlang projects.
- Zero preparation of existing projects before the first run.
- Allow gradual introduction of type specs, be gentle with unspecced
code.
- The author will be aiming for a simple prototype.

[Nicolas Martyanoff]

Is there a reason not to use the already existing type definitions and
annotations ? They are already gradual, since you are not forced to
annotate everything, you have total control on the granularity (you can
use any() as much as you want), and they do not require introducing what
is in practice a new language (which would requires new parsers in code
editors, new tools, etc.).

While getting Dialyzer to the state of the art would be fantastic,
writing a totally new type checker based on the same annotations would
work as well, and would avoid having to maintain any type of
compatibility with the current behaviour of Dialyzer.

If you work on that subject, feel free to contact me in PM, I would be
happy to test your work on my codebases.

[Dmytro Lytovchenko]

After giving it a thought, it is clear to me, that before starting its run,
the tool must see entire program data (not necessarily entire program
source, but a PLT-like database of type facts from other modules of the
same program) just like Dialyzer does with PLT and loading entire codebase.
This means it cannot be a direct drop-in replacement for `erlc`, more like
a build tool with a project file which you have to provide to let it know
input directories and compiler options.

And after giving it another thought, it is more within my priorities to
actually use `-spec ...` blocks instead of adding new syntax.

Then this begins looking more like a fusion of `lib/compiler` and
`lib/dialyzer` from OTP. In that case it is not a low hanging fruit anymore.
Will continue my thought experiment and do some experimental coding.

Post by Nicolas Martyanoff
Is there a reason not to use the already existing type definitions and
annotations ? They are already gradual, since you are not forced to
annotate everything, you have total control on the granularity (you can
use any() as much as you want), and they do not require introducing what
is in practice a new language (which would requires new parsers in code
editors, new tools, etc.).
While getting Dialyzer to the state of the art would be fantastic,
writing a totally new type checker based on the same annotations would
work as well, and would avoid having to maintain any type of
compatibility with the current behaviour of Dialyzer.
If you work on that subject, feel free to contact me in PM, I would be
happy to test your work on my codebases.
--
Nicolas Martyanoff
http://snowsyn.net