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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210606/aecf242c/attachment.htm>