pixels = <<213, 45, 132, 64, 76, 32, 76, 0, 0, 234, 32, 15>>
for <<r::8, g::8, b::8 <- pixels>>, do: {r, g, b}
#⇒ [{213, 45, 132}, {64, 76, 32}, {76, 0, 0}, {234, 32, 15}]
mudasobwa
Creator of Cure
1
iamafanasyev
Nice!
However, we can discuss this case, since streams are lazy:
λ (stream x <- [1, 2], x > 2, y <- [0], do: x * y) |> Enum.to_list
[]
λ (stream x <- [1, 2], x > 2, y <- [raise "boom"], do: x * y) |> Enum.to_list
** (RuntimeError) boom
0
hst337
That’s a common misconception. for is always translated into Enum.reduce and :lists.reverse. You can check the debug info in the beam file
iex(1)> defmodule X do
...(1)> def f(list) do
...(1)> for x <- list, do: x
...(1)> end
...(1)> end
{:module, X,
<<70, 79, 82, 49, 0, 0, 5, 220, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 0, 206,
0, 0, 0, 22, 8, 69, 108, 105, 120, 105, 114, 46, 88, 8, 95, 95, 105, 110,
102, 111, 95, 95, 10, 97, 116, 116, 114, ...>>, {:f, 1}}
iex(2)> {_, _, b, _} = v
iex(3)> :beam_lib.chunks b, [:abstract_code]
...
{:function, 2, :f, 1,
[
{:clause, 2, [{:var, 2, :_list@1}], [],
[
{:call, 3, {:remote, 3, {:atom, 3, :lists}, {:atom, 3, :reverse}},
[
{:call, 3, {:remote, 3, {:atom, 3, Enum}, {:atom, 3, :reduce}},
[
{:var, 3, :_list@1},
{nil, 3},
{:fun, 3,
{:clauses,
[{:clause, 3, [{:var, 3, ...}, {:var, ...}], [], [{...}]}]}}
]}
]}
]}
]}
...
I have a project which optimizes such behaviour: GitHub - hissssst/tria: Elixir optimizing compiler · GitHub
3
hst337
I got your point, and I’ve provided an example to show why nobody uses Stream.resource for managing resources and why it’s actually a bad idea. Stream.resource is an optimistic way to manage resources, and it has a lot of flaws (like leaving resource open in case of infinite recursion bug, memory limit, etc.) . As I’ve said, an idiomatic way to manage resources is using a separate monitoring process.
2
iamafanasyev
Seems like we can safely refactor timeout-divergence into separate risk. Say we have some facility to run the expression evaluation within the provided timeout, so we can always apply time bound externally (e.g. on the client side). By the way, using Stream.resource/3/try-rescue in WithTimeout looks safe, since the only thing performed on the resource (Task.Supervisor) is spawning task to await.
Good insights. For example, the one on a data copying concern (addressed in DBConnection.Holder). Again as a sidenote — Stream.resource/3/try-rescue does everything in-place, so no cost on copy messages.
That is tough! Agree, an existing library for such case would be Elixir (Erlang) itself.
To sum up on fault tolerance:
- While
ResourceusesStream.resource/3under the hood, it could be seen as a solution for the same class of problems, one can approach withStream.resource/3(up to resource streaming necessity); - timeout-divergence could be addressed on demand (applying time bounds on the resource usage).
And yes, Resource is not the way you should approach highly specific resource management domains (e.g. HTTP connection pools). Now I see, that Resource’s name could be slightly misleading in such a context. Its focus is mainly not on the resource object itself (there could be no “object” at all), but on the “bracketing-the-usage” ceremony (do this on acquire, do that on release).
But I’ll try to dig more on Stream.resource/3 backend alternative.
0
iamafanasyev
Hey, guys, I’m back 
Thanks for @hst337 good points, I was able to release 1.0.0 and 1.1.0 versions of the library:
- 1.0.0 introduces an Elixir way to write for-comprehension (yep, macro application to
Kernel.SpecialForms.for/1solves the variadic-problem); - 1.1.0 extends 1.0.0 with pattern matching filtration semantics across generated values (that was really fun challenge to implement saving all native compile-time warnings[1]).
So now the main focus of these releases was on extending already existing Elixir’s for-comprehension syntax to work with “other-for-comprehendable-structures” and both syntactically and effectively be as close as possible to Kernel.SpecialForms.for/1 on List’s. As a result I end up with identical to Elixir’s for-comprehension syntax up to macro application of cause (well and Kernel.SpecialForms.for/1’s exclusive reduce syntax/semantics, there is no such in bindable-for):
import Bindable.ForComprehension
xs = [[], [2, 2], [3], [4]]
xys = [[1, 1], [2, 2], [3, 3], [4, 4]]
bindable for [x] <- xs, # pattern matching guard
[^x, y] <- xys, # pattern matching guard with ^ operator
y > 0, # "conventional" guard
do: [x, y]
# [[3, 3], [4, 4]]
As always happy to hear your thoughts and critics on the subject, cheers 
[1] — match?/2 may generate unused variable warnings, when the pattern contains (in some sense) “free” variables, e.g. match?([x], [42]) or simply match?(x, 42); function head definitions could also generate warnings about “unreachable head”, e.g. fn x -> 42; _ -> :causes_warning end; so the answer was with/1, that provides pattern matching, assigns and a (do-)scope to work across.
2