bvobart
How to define the type of a Stream with a specific type of elements?
For a list of integers, I can simply write a typespec like this:
@type foo() :: [integer()] # or list(integer())
But what about a Stream of integers?
There is no Stream.t() or Stream.t(element_type) and Enum.t() does not allow any type information about the elements. There is Enumerable.t(), which is what Stream.resource/3’s return type is typed as, and it accepts a type argument, so Enumerable.t(integer()) is a valid way of defining an Enumerable containing integers. However, that still equates to term() so it doesn’t give any type guarantees about the elements returned from the Enumerable or Enum functions.
Also, I want it to be clear to users of my functions that the function returns a Stream-like object where it is advisable to use Stream functions instead of Enum functions. Consider the following example:
defmodule MyApp.SomeStruct do
@type t() :: __MODULE__{foo: integer(), bar: String.t()}
defstruct foo: 0, bar: ""
@doc """
Stream a bunch of SomeStruct objects from a JSON lines file.
"""
@spec stream(String.t()) :: Enumerable.t(t())
def stream!(filename) do
filepath |> File.stream!() |> Stream.map(fn line -> line |> JSON.decode!() |> decode() end)
end
@spec decode!(map()) :: t()
def decode!(data) do
%MyApp.SomeStruct{foo: data["foo"], bar: data["bar"]} # contrived example
end
end
Currently, I use Enumerable.t(t()) instead of [t()] to indicate that we’re not returning a list, but more generically we’re returning an Enumerable. But actually, I want to say “hey this is a Stream, I recommend using Stream methods and only using an Enum method when you actually want to start consuming the items from this stream. Oh, and the items are of type t()”.
Is there currently a way in Elixir to write such a type? Or are there plans to support such a feature in Elixir’s type system?
Most Liked
al2o3cr
IMO this highlights a big difference between “parameterized types” (the typespec system) and other systems like Rust’s generics.
Parameterized types are better thought of as compile-time functions that produce types. They always require fully-defined arguments and don’t support inference-like patterns.
For instance, you can’t write a signature like this:
# THIS DOES NOT WORK
@spec generic_filter(Enumerable.t(x), (x -> as_boolean(term()))) :: Enumerable.t(x)
Making a Stream.t(element_type) would also have the complication that there’s no obvious place to put element_type in the resulting %Stream{}; it’s not necessarily the type of the contained enum since funs are applied, and it’s only related to the top element of funs.
LostKobrakai
There cannot be any type guarantees for protocol implementations just like there cannot be type guarantees around behaviours. Dynamic dispatch cannot have correctness enforced at compile time for as long as valid implementations can be added at runtime – by adding additional modules.
Behaviour types all come down to module() and eventually atom() in typespecs, protocols can implemented for any term, so that’s what you ran into. If a provided atom actually references a module implementing an expected behaviour or if a given term has a related protocol implementation cannot be determined at compile time.
That’s imo a misunderstanding of the enumerable protocol. There is no stream just like there’s no “not a stream”. They’re all Enumerables, potentially infinite in length. The difference between Stream and Enum is not in the source data, the difference is in the processing / how they work over enumerables. And the caller decides to either process lazily (e.g. stream apis) or processes eagerly (e.g. enum apis).
LostKobrakai
Totally impossible given you can defmodule a new module at any time or replace an existing one – even at runtime. Most famously that’s how hot code updates work. The typesystem could make assumptions of no runtime created modules, but I wouldn’t expect that to happen.
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Courses that'll move you from confusion to "Aha, now I get it!"
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #hex
- #security
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking for Elixir devs who love to ship. Start your free account.
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"