Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parametrized remote types for protocols #7541

Closed
paulperegud opened this issue Apr 9, 2018 · 17 comments
Closed

Parametrized remote types for protocols #7541

paulperegud opened this issue Apr 9, 2018 · 17 comments

Comments

@paulperegud
Copy link

Being able to parametrize types ([pos_integer()]) is a critical feature of dialyzer. Support for parametrization is extended to some of remote types (:queue.queue(pos_integer())) but unfortunately not to all of them.

One I miss it the most ability to parametrize Enum (Enum.t(pos_integer())).

@josevalim josevalim changed the title feature request: parametrized remote types for typespec Parametrized remote types for protocols Apr 9, 2018
@ericmj
Copy link
Member

ericmj commented Apr 9, 2018

Parameterized types for protocols can be useful for documentation but I don't believe they will help dialyzer analysis.

@josevalim
Copy link
Member

@ericmj they should help once protocols are consolidated, which are most of the cases now.

@michalmuskala
Copy link
Member

michalmuskala commented Apr 9, 2018

It won't help with protocols themselves, but it should with things that use them. For example, we could make spec for Enum.map to be @spec map(t(a), (a -> b)) :: t(b). It is my understanding, it would improve analysis in places where Enum.map is used (but not for Enum.map itself - that's perfectly fine).

@ericmj
Copy link
Member

ericmj commented Apr 9, 2018

@josevalim Do we consolidate the typespecs as well? Otherwise I don't think Dialyzer can make the connection since the type has to be based on term: @type t(inner) :: term.

@josevalim
Copy link
Member

@ericmj that will be part of the work that needs to be done. :) Yes.

@ericmj
Copy link
Member

ericmj commented Apr 9, 2018

Can you elaborate on how would that work?

@josevalim
Copy link
Member

josevalim commented Apr 9, 2018 via email

@ericmj
Copy link
Member

ericmj commented Apr 9, 2018

How do we know the shape of the types we dispatch on, do you mean we should assume that ImplModule.t is the type? What if the implementation type has a different number of parameters?

@josevalim
Copy link
Member

josevalim commented Apr 9, 2018 via email

@fertapric
Copy link
Member

Here is an idea.

Protocol might use a module attribute @typeprotocol (or @type_protocol) or a macro to define the signature of the types; and the implementation might optionally define the types specified in the protocol using the regular @type syntax. During the consolidation process, the types defined in the protocol would be generated by inspecting the typespecs of the different implementations.

Here is an example:

defprotocol MyProtocol do
  @typeprotocol t()
  @typeprotocol t(my_type)
  
  @spec my_fun(t) :: boolean
  def my_fun(term)
end

defimpl MyProtocol, for: Foo do
  @type t(a) :: list(a)
  
  def my_fun(term) do
    true
  end
end

Thoughts?

@josevalim
Copy link
Member

josevalim commented Dec 13, 2018

@fertapric that's a step in the right direction. The only issue is that @type/@spec/@opaque/@typep are specialish and I wouldn't want to introduce another special module attribute. But we could do it with something like:

defprotocol MyProtocol do
  @type t()
  @type t(my_type)
  @protocol_types t: 0, t: 1

  @spec my_fun(t) :: boolean
  def my_fun(term)
end

Or something of sorts.

@CptBreeza
Copy link

Any further progress on this?

@Qqwy
Copy link
Contributor

Qqwy commented Oct 12, 2021

Can someone explain why we would need special support for parameterized protocol types?

Given that:

  • We can @spec private functions.
  • We can freely add custom @types and @specs to both our defprotocol module and our defimpl modules

-> it should be possible to generate the consolidated protocol module in a way where protocol dispatch calls the particular private function implementation taken from the particular defimpl which will receive any @spec(s) indicated for that particular implementation.

Am I missing something?

@josevalim
Copy link
Member

We need to rewrite the protocol types to point only to the possible implementations, instead of today’s term. I.e, we need to make Enumerable.t(integer) point to t/1 of each implementation.

@josevalim
Copy link
Member

We no longer plan to explore this for now, as there is research on a new type system, which could have first class support for protocols, rather than enabling this on top of Dialyzer.

@josevalim josevalim closed this as not planned Won't fix, can't repro, duplicate, stale Jul 27, 2022
@Papipo
Copy link

Papipo commented Mar 10, 2023

@josevalim where can I read about that and what's it status? Thanks! 🙇🏽

@josevalim
Copy link
Member

The official Elixir blog is where we will post updates. The last one was: https://elixir-lang.org/blog/2022/10/05/my-future-with-elixir-set-theoretic-types/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

8 participants