Opinions wanted: A superset of regular Erlang for type checking and deduction
Sun Jun 6 17:00:51 CEST 2021
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.
On Sun, 6 Jun 2021 at 12:33, Nicolas Martyanoff <khaelin@REDACTED> wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions