What you are thinking about would be very possible if the elixir compiler emitted a message to hooks when a “def”/“defp” macro gets compiled, containing the finalized ast of the function. I think it would be safe because in general hooks don’t let you modify the actual code in-flight.
ityonemo
baldwindavid
@Qqwy - You mention that TypeCheck complements some compile-time checks. I know that @ityonemo is just at the outset of work on Selectrix, but is it accurate that these two projects could also possibly complement each other whereby Typecheck provides runtime checks via macro and also generates typespecs for which Selectrix uses for compile time checks?
I’m already getting great value out of TypeCheck and Selectrix sounds interesting. Is there any opportunity for collaboration between the projects or is that mostly unnecessary or detrimental to each? My hope is that these sorts of concepts end up in core one way or another.
0
ityonemo
happy to collaborate! I have some “unusual” ideas about BEAM types that I’ve outlined in https://github.com/ityonemo/mavis/blob/master/typesystem.md, which is why i’ve broken this out into a separate library, in case my ideas are too crazy. However, everything will use typespecs at the end, and I’m not even parsing them, I’m pulling them from the module binaries, so it should “just work” with TypeCheck.
It would be very reasonable to use TypeCheck to generate runtime checks (for dev and test) and use Selectrix for compile-time guards. Selectrix would keep your type logic correct and TypeCheck would keep your type declarations honest. I believe these are orthogonal concerns and Selectrix “depends” on the fact that the declarations are correct; IIRC TypeCheck won’t tell you AOT that you’re plugging a square peg into a round hole.
3
baldwindavid
Cool. Seems like both projects are all-in on leveraging typespecs. As for far future, I was surprised to see that José does not seem to be too excited about typespecs, but I guess more important to get something working and useful rather than worrying about whether there is any chance at ever getting it into core.
3
ityonemo
I am definitely discovering warts in the erlang typespec system as I go along. The biggest one is what does it mean when a map requires a type that is a collection (it’s sensible when the type is a singleton, like literal atom or literal number). I’m still not 100% sure what I want to do in that case.
2
zimt28
I just created a new Phoenix project, added type_check and always get this error:
** (Mix) Could not start application stream_data: could not find application file: stream_data.app. Do I need to setup anything else?
0
Qqwy
TypeCheck Core Team
Thank you for mentioning!
As a quick fix, try installing :stream_data as extra dependency.
However, I’ll investigate what is going on here because :stream_data is supposed to be an optional dependency so TypeCheck should still work when it is not available. I made an issue here
1
zimt28
Great, thanks! I also noticed that I cannot do something like
@spec! fun(Ecto.Changeset.t()) :: Ecto.Changeset.t()
It tells me that function Ecto.Changeset.t/0 is undefined or private. Is this some misunderstanding on my side, a bug or a limitation of TypeCheck?
0
baldwindavid
Ecto is an external library and would not have a t function defined. The t type is, by convention, added for your own structs. For example, in a User module you might have the following from the docs:
@type! t :: %User{name: binary, age: integer}
This can then be used at a callsite as…
@spec! my_fun(User.t()) :: User.t()
This allows you to ensure that a received argument is not only a User struct, but also that its name is a binary and age is an integer.
If you didn’t care about requiring those types, this would also work…
@spec! my_fun(%User{}) :: %User{}
This tells you that you can do the same with any struct. So in the case of a changeset, you can use…
@spec! fun(%Ecto.Changeset{}) :: %Ecto.Changeset{}
As an example, you can even make your own custom types such as this one:
@type! error_changeset() :: {:error, %Ecto.Changeset{}}
This can be used at the callsite with…
@spec! fun(%Ecto.Changeset{}) :: error_changeset()
In practice, I’ve found that I need only a handful of custom types (other than t definitions). The library provides you with most of the builtins you would expect with regular typespecs.
2
Qqwy
TypeCheck Core Team
To add to what @baldwindavid already said: It is somewhat of a current limitation of TypeCheck. As TypeCheck does not infer its type from pre-existing already-compiled typespecs (but rather the other way around, building typespecs as well as runtime-checks and property-test-generators from the written signature) it cannot handle types that were written in other libraries/modules that did not use TypeCheck.
At some point in the near future, TypeCheck will implement all remote types that are builtin in the Elixir core libraries themselves (c.f. issue #5). Besides this, my current idea of making TypeCheck work well with existing libraries that did not use TypeCheck is to allow you to configure a couple of overrides in your application, saying essentially “if you encouter Ecto.Changeset.t(foo), replace it by …”.
Until this is implemented, your best bet is to use the strategies that @baldwindavid mentioned above. Since Ecto.Changeset.t is a public type, you might even use %Ecto.Changeset{data: User.t()}.
2