Adding more input consumers about gradualizer HOT 10 CLOSED

This is great!

I think it'd be nice to have this as part of the Gradualizer repo, so long as we can make sure that people can build and run Gradualizer without depending on Elixir. But that shouldn't be a problem afaics.

As for the naming, I'm in two minds about it. On the one hand it's nice to have just one name for the tool even though it can handle different languages. On the other hand we have the precedence of Dialyxir, which perhaps makes people expect there to be a Gradualixir.
Whatever naming you choose, I think the name of the tool should coincide with the name of the mix target. Right now the tool is called Gradualixir but when using it we type mix gradualizer. That seems somewhat confusing.

from gradualizer.

Speaking of tools, is there any objection to a mix plugin being made that wraps gradualizer? I've started one but it's not yet published.

from gradualizer.

Ah, apparently there is a type_check_forms in the typechecker module, any chance of that being forwarded from the main gradualizer module as well for a single API entrance module?

from gradualizer.

We have gradualizer:type_check_module which checks loaded beam files (or they will be loaded if available in the path). Would that work for you?
That's not to say that I'm opposed to adding new functions to the gradualizer module though. Though it'd be good to hear more about the particular use-case you have in mind.

As for a mix plugin, I'd love to see such a thing! Feel free to send a PR.

from gradualizer.

We have gradualizer:type_check_module which checks loaded beam files (or they will be loaded if available in the path). Would that work for you?

Not necessarily, things like escripts won't contain beam files on the filesystem, languages like Elixir do a LOT of code generation that exists purely in memory (but you can query it for the beam data) at compile-time that don't get generated for runtime, etc... etc... Do note this includes modules that are compiled to BEAM data but never exist on disk or are loaded into the runtime (such as for code generation).

As for a mix plugin, I'd love to see such a thing! Feel free to send a PR.

Let me go ahead and github the little bit that I have so far, sec...

from gradualizer.

Made a simple README before uploading it, now available at: https://github.com/OvermindDL1/gradualixir

The tests fail because of the error of:

_build/test/lib/gradualixir/ebin/Elixir.Gradualixir.beam: The binary [{bin_element,0,{string,0,"*.beam"},default,default}] on line 0 does not have type t()

That is the error I added in my local edited gradualizer so I could get something readable. ^.^

from gradualizer.

Do you want the mix plugin to remain standalone or do you want it added to gradualizer itself? It can be written in Erlang though some manual hoisting of some of the macro'd code would be required then. Right now it's just following the Gradualizer->Gradualixir naming and usage conventions that the Dialixir project did for Dialyzer.

from gradualizer.

Right now the tool is called Gradualixir but when using it we type mix gradualizer. That seems somewhat confusing.

It's following the same pattern of dialyzer/dialixir, it does the same thing. You are running the 'command' gradualizer but the mix integration is just called gradualixir. Though if it is integrated straight in to here then that would be dropped of course.

To fullfill the mix plugin api you need a specially named module, not too hard to do (you can essentially just rewrite what I did into erlang), or it can be kept as elixir anyway (since mix is built in elixir so if someone has mix then they have elixir) and just have both elixir and rebar build systems in the repo at the same time (entirely supported).

EDIT: Oh, and of course this would need to be 'published' to some library repository like hex or so (anything that is fully supported by both rebar and mix is fine, and everything seems to use hex anymore anyway).

from gradualizer.

Sounds good. I don't have a strong opinion on the naming since I'm not an Exilir programmer myself.

I'm happy to include the Elixir module providing mix support and it can live side-by-side with rebar as you explained.

Please submit a PR!

As for publishing it to hex, I'd like to get to a point where we support all language constructs in the abstract format. We're close now, but now quite there yet.

from gradualizer.

As for publishing it to hex, I'd like to get to a point where we support all language constructs in the abstract format. We're close now, but now quite there yet.

That is what versions <1.0.0 are for on hex, and you can even deprecate them upon a full 1.0.0 release, but putting out 0.x.y releases mean that more testing can more easily be done. :-)

from gradualizer.