I like the original idea and would like to suggest another approach. What if 
there were an additional Inspect.Opts of :transform? It then would enable this 
sort of thing:

["thing1", "thing2"]
|> generate_more_things()
|> IO.inspect(transform: &length/1)
|> do_something_with_things()

-Greg Vaughn

> On Jan 12, 2018, at 5:18 PM, José Valim <[email protected]> wrote:
> 
> Thanks for the proposal!
> 
> Unfortunately that would make us unable to inspect functions themselves, 
> which is a valid argument to IO.inspect after all.
> 
> Imagine the confusion of trying to inspect a pipeline that may emit an 
> anonymous function only to find it is being executed instead.
> 
> 
> 
> José Valim
> www.plataformatec.com.br
> Founder and Director of R&D
> 
> On Fri, Jan 12, 2018 at 10:59 PM, <[email protected]> wrote:
> I often find myself wanting to inspect things in the middle of a chain of 
> pipes, but I don’t always want to inspect the return values as-is. Sometimes 
> I want to inspect sub-attributes or call functions on the return values to 
> inspect them.
> 
> For example, imagine the contrived pipeline below.
> 
> ["thing1", "thing2"]
> |> generate_more_things()
> |> do_something_with_things()
> 
> If I want to know the length of the list returned by generate_more_things/1, 
> I would do this:
> 
> ["thing1", "thing2"]
> |> generate_more_things()
> |> (fn things ->
>   things |> length() |> IO.inspect()
>   things
> end).()
> |> do_something_with_things()
> 
> If IO.inspect can take a function as an argument, print the inspection of the 
> result of calling that function, but still return the un-altered input, I 
> could do this:
> 
> ["thing1", "thing2"]
> |> generate_more_things()
> |> IO.inspect(fn things -> length(things) end)
> |> do_something_with_things()
> 
> Or even:
> 
> ["thing1", "thing2"]
> |> generate_more_things()
> |> IO.inspect(&length/1)
> |> do_something_with_things()
> 
> I think this would aid during debugging and be a useful feature in the 
> standard library. I'd love to implement and contribute on this, but I wanted 
> to see if such a thing would be accepted before beginning work.
> 
> Open to feedback!
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "elixir-lang-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/elixir-lang-core/4e2bfad0-b745-4059-8736-996e641c7bb2%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "elixir-lang-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KAvw%2BwWnh7d60%3DvKEkuLvWfyoh4XuM9rbuxz_CaLg9%3DA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/6CF01F3F-5848-4E19-BCA1-9D256824D6E0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to