for let x = 10, let y = 12, foo <- list do
{result, x, y}
end
Sent via Superhuman iOS ( https://sprh.mn/?vip=zachary.s.dan...@gmail.com )
On Tue, Dec 21 2021 at 4:35 PM, Zach Daniel < zachary.s.dan...@gmail.com >
wrote:
>
> I really like this, and would be happy with it as is 😁 I have one thought
> though, with the way that we are already doing a bit of “magic” (I don’t
> mean that in a negative way) to map the “let” variable to the second
> element of the tuple, could we support multiple assignments without the
> tuple in the let? Something like this (hard to type code on the phone 😂)
>
>
>
>
> for let x = 10, y = 12, foo <- list do
> {result, x, y}
> end
>
>
> Sent via Superhuman iOS ( https://sprh.mn/?vip=zachary.s.dan...@gmail.com )
>
>
>
>
> On Tue, Dec 21 2021 at 4:09 PM, Stefan Chrobot < ste...@chrobot.io > wrote:
>
>
>> I'm too voting in favor of the proposal in the current form. Unsure about
>> the parens, but looking forward to some way of replacing reduce_while with
>> some version of the for.
>>
>>
>> Best,
>> Stefan
>>
>> wt., 21 gru 2021 o 21:47 Christopher Keele < christheke...@gmail.com >
>> napisał(a):
>>
>>
>>> *Guides Feedback*
>>> *
>>> *
>>> These look excellent, should make the power of for much more accessible.
>>> *
>>> *
>>> *let Feedback*
>>>
>>>
>>> I like the functionality of this proposal much more!
>>>
>>>
>>> I will say, I'm still not a fan of using new qualifiers. I'm not sure why
>>> we need to introduce a new special form for this, since we can do whatever
>>> we need to in the macro? What's wrong with:
>>>
>>>
>>> > for count = 0, count < 5, x <- element do {x, count + 1} end
>>>
>>>
>>> Perfectly matches traditional for loops, and pattern matching in function
>>> arguments, with all the familiar errors/warning possibly emitted from
>>> them, while keeping the bodies identically functionally-refactorable. No
>>> let
>>> s needed.
>>>
>>> Re: for reduce , since for already has idiomatic keyword arguments to
>>> further modify functionality, isn't :reduce is doing fine as is? We'd just
>>> document how it interacts with for-bindings.
>>>
>>>
>>> > Furthermore, the introduction of let and reduce qualifiers opens up the
>>> option for new qualifiers in the future, such as for async that is built
>>> on top of Task.async_stream/3.
>>> >
>>> > Async doesn't have its own arguments
>>>
>>> (
>>> https://gist.github.com/josevalim/fe6b0bcc728539a5adf9b2821bd4a0f5#naming
>>> )
>>>
>>>
>>> Similarly, I'm unsure what's wrong with add an async: true keyword
>>> argument. It's just behaviour configuration, not something we need to
>>> bring to the forefront as a pattern match?
>>>
>>>
>>> *Replies*
>>> *
>>> *
>>> > I am against the notion of `for_let` and `for_reduce`. I see that as
>>> using up more of the special forms "namespace".
>>>
>>>
>>> Agreed, mirroring my misgivings about "for let" and "for reduce".
>>> On Tuesday, December 21, 2021 at 11:58:19 AM UTC-5 gva...@gmail.com wrote:
>>>
>>>
>>>
>>>> I'm a vote in favor of the proposal. I think I have a slight preference
>>>> for the parens. But it's very slight, and I'm not sure I wouldn't change
>>>> my mind after using it for a while.
>>>>
>>>>
>>>> I am against the notion of `for_let` and `for_reduce`. I see that as using
>>>> up more of the special forms "namespace".
>>>>
>>>>
>>>> I'm slightly disappointed that the old style `reduce:` option will be
>>>> deprecated (because I have old code I'll have to update) however, the
>>>> change does make things more consistent and I appreciate the thought about
>>>> future extensions to for comprehensions.
>>>>
>>>>
>>>> -Greg Vaughn
>>>>
>>>>
>>>> PS. I just watched your latest Twitch stream. I wish I could have been
>>>> there live to hear you read the dictionary and to offer obscure English
>>>> words to the bikeshed discussion :-D
>>>>
>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>> On Dec 21, 2021, at 3:31 AM, José Valim < jose....@dashbit.co > wrote:
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>> Compared to the previous proposal, this one has been very quiet so far. :)
>>>>> I am unsure if it was because it was a Monday or because holidays are
>>>>> coming, so I am sending a ping.
>>>>>
>>>>>
>>>>> ALso note I updated the proposal to not use parens around let/reduce,
>>>>> which seems to be the preference so far:
>>>>> https://gist.github.com/josevalim/fe6b0bcc728539a5adf9b2821bd4a0f5
>>>>>
>>>>>
>>>>> On Tue, Dec 21, 2021 at 1:29 AM 'eksperimental' via elixir-lang-core <
>>>>> elixir-l...@googlegroups.com
>>>>> > wrote:
>>>>>
>>>>>
>>>>>> Not necessarily that they are replaceable,
>>>>>> but that pattern of :cont, :halt, :suspend is most commonly used via
>>>>>> Enumerable.reduce
>>>>>>
>>>>>>
>>>>>> On Mon, 20 Dec 2021 19:18:53 -0500
>>>>>> "'eksperimental' via elixir-lang-core"
>>>>>> < elixir-l...@googlegroups.com > wrote:
>>>>>>
>>>>>> > > I have found only one usage of Enum.reduce_while in Elixir's
>>>>>> > > codebase.
>>>>>> >
>>>>>> > This is because under the hood Enum.reduce_while is a call
>>>>>> > `Enumerable.reduce/3`, so we are invoking this functions direcly.
>>>>>>
>>>>>> >
>>>>>> > On Tue, 21 Dec 2021 00:47:44 +0100
>>>>>> > Stefan Chrobot < ste...@chrobot.io > wrote:
>>>>>> >
>>>>>> > > Thanks, that version would work, but agreed - not sure how big of an
>>>>>> > > improvement that would be over Enum.reduce_while. Trying to think
>>>>>> > > about this in a more imperative style, it seems that maybe an
>>>>>> > > equivalent of break is what I'm after? Maybe something close to
>>>>>> > > Ecto's Repo.transaction semantics?
>>>>>> > >
>>>>>> > > for foo <- foos do
>>>>>> > > case barify(foo) do
>>>>>> > > {:ok, bar} -> bar
>>>>>> > > {:error, reason} -> break(reason)
>>>>>> > > end
>>>>>> > > end
>>>>>> > >
>>>>>> > > I think this would have to work similarly to how Ecto's transactions
>>>>>> > > work with Multis, that is return {:ok, bars} or {:error, reason,
>>>>>> > > data_so_far}.
>>>>>> > >
>>>>>> > > I have found only one usage of Enum.reduce_while in Elixir's
>>>>>> > > codebase. Interestingly, the shape of the return value is always
>>>>>> > > the same - a list of finished tests.
>>>>>> > > https://github.com/elixir-lang/elixir/blob/main/lib/ex_unit/lib/ex_unit/runner.ex#L340
>>>>>>
>>>>>> > >
>>>>>> > > This seems like a separate problem, but maybe something to keep in
>>>>>> > > mind.
>>>>>> > >
>>>>>> > > Best,
>>>>>> > > Stefan
>>>>>> > >
>>>>>> > >
>>>>>> > > wt., 21 gru 2021 o 00:21 Ben Wilson < benwil...@gmail.com >
>>>>>> > > napisał(a):
>>>>>> > >
>>>>>> > > > To revisit the example situation from the original post:
>>>>>> > > >
>>>>>> > > > ```
>>>>>> > > > {sections, _acc} =
>>>>>> > > > for let {section_counter, lesson_counter} = {1, 1}, section <-
>>>>>> > > > sections do lesson_counter = if section["reset_lesson_position"],
>>>>>> > > > do: 1, else: lesson_counter
>>>>>> > > > {lessons, lesson_counter} = for let lesson_counter, lesson <-
>>>>>> > > > section["lessons"] do
>>>>>> > > > {Map.put(lesson, "position", lesson_counter), lesson_counter + 1}
>>>>>> > > > end
>>>>>> > > > section =
>>>>>> > > > section
>>>>>> > > > |> Map.put("lessons", lessons)
>>>>>> > > > |> Map.put("position", section_counter)
>>>>>> > > >
>>>>>> > > > {section, {section_counter + 1, lesson_counter}}
>>>>>> > > > end
>>>>>> > > > ```
>>>>>> > > >
>>>>>> > > > I think that's nice! It focuses on inputs and outputs and reduces
>>>>>> > > > the overall line noise.
>>>>>> > > >
>>>>>> > > > On Monday, December 20, 2021 at 5:28:29 PM UTC-5 José Valim wrote:
>>>>>> > > >
>>>>>> > > >> Stefan, this would work if we include all extensions:
>>>>>> > > >>
>>>>>> > > >> for reduce {status, acc} = {:ok, []}, status == :ok, foo <- foos
>>>>>> > > >> do case barify(foo) do
>>>>>> > > >> {:ok, bar} -> {:ok, [bar | acc]}
>>>>>> > > >>
>>>>>> > > >> {:error, _reason} = error -> error
>>>>>> > > >> end
>>>>>> > > >> end
>>>>>> > > >>
>>>>>> > > >> I am not sure if you find it any better. It is hard to do this
>>>>>> > > >> with "let" because you don't want to include the element of when
>>>>>> > > >> it fails.
>>>>>> > > >>
>>>>>> > > >> On Mon, Dec 20, 2021 at 9:23 PM Stefan Chrobot
>>>>>> > > >> < ste...@chrobot.io > wrote:
>>>>>> > > >>> I went through some of our code and one thing I'd love to see is
>>>>>> > > >>> a way to replace Enum.reduce_while with the for comprehension.
>>>>>> > > >>> So the code like this:
>>>>>> > > >>>
>>>>>> > > >>> Enum.reduce_while(foos, {:ok, []}, fn foo, {:ok, bars} ->
>>>>>> > > >>> case barify(foo) do
>>>>>> > > >>> {:ok, bar} -> {:cont, {:ok, [bar | bars]}}
>>>>>> > > >>> {:error, _reason} = error -> {:halt, error}
>>>>>> > > >>> end
>>>>>> > > >>> end)
>>>>>> > > >>>
>>>>>> > > >>> Would the following even work?
>>>>>> > > >>>
>>>>>> > > >>> for reduce(result = {:ok, []}), foo <- foos, {:ok, _} <- result
>>>>>> > > >>> do case barify(foo) do
>>>>>> > > >>> {:ok, bar} -> {{:ok, [bar | bars]}}
>>>>>> > > >>> {:error, _reason} = error -> {error}
>>>>>> > > >>> end
>>>>>> > > >>> end
>>>>>> > > >>>
>>>>>> > > >>> Even if it did, it's not doing a great job of communicating the
>>>>>> > > >>> intent and still potentially requires a Enum.reverse call. The
>>>>>> > > >>> intent here is "early exit with some value upon some condition
>>>>>> > > >>> or pattern mismatch".
>>>>>> > > >>>
>>>>>> > > >>>
>>>>>> > > >>> Best,
>>>>>> > > >>> Stefan
>>>>>> > > >>>
>>>>>> > > >>> pon., 20 gru 2021 o 21:06 Stefan Chrobot < ste...@chrobot.io >
>>>>>> > > >>> napisał(a):
>>>>>> > > >>>> I really like this proposal! For me it strikes the perfect
>>>>>> > > >>>> balance between terseness and explicitness that I've come to
>>>>>> > > >>>> enjoy in Elixir.
>>>>>> > > >>>>
>>>>>> > > >>>> My votes:
>>>>>> > > >>>> - Naming: let over given; just because it's shorter,
>>>>>> > > >>>> - Do use parents: let "feels" similar to var!.
>>>>>> > > >>>>
>>>>>> > > >>>> Best,
>>>>>> > > >>>> Stefan
>>>>>> > > >>>>
>>>>>> > > >>>> pon., 20 gru 2021 o 19:54 José Valim < jose....@dashbit.co >
>>>>>> > > >>>> napisał(a):
>>>>>> > > >>>>> Good point. I forgot to mention the :reduce option will be
>>>>>> > > >>>>> deprecated in the long term.
>>>>>> > > >>>>>
>>>>>> > > >>>>> On Mon, Dec 20, 2021 at 7:53 PM 'eksperimental' via
>>>>>> > > >>>>> elixir-lang-core < elixir-l...@googlegroups.com > wrote:
>>>>>> > > >>>>>
>>>>>> > > >>>>>> The proposal is very concise,
>>>>>> > > >>>>>> the only thing that would be problematic is the use of
>>>>>> > > >>>>>> `reduce` for two
>>>>>> > > >>>>>> different things,
>>>>>> > > >>>>>>
>>>>>> > > >>>>>> for <<x <- "AbCabCABc">>, x in ?a..?z, reduce: %{} do
>>>>>> > > >>>>>> acc -> Map.update(acc, <<x>>, 1, & &1 + 1)
>>>>>> > > >>>>>> end
>>>>>> > > >>>>>>
>>>>>> > > >>>>>> {sum, count} =
>>>>>> > > >>>>>> for reduce({sum, count} = {0, 0}), i <- [1, 2, 3] do
>>>>>> > > >>>>>> sum = sum + i
>>>>>> > > >>>>>> count = count + 1
>>>>>> > > >>>>>> {sum, count}
>>>>>> > > >>>>>> end
>>>>>> > > >>>>>>
>>>>>> > > >>>>>> It would lead to misunderstanding as it may not be clear
>>>>>> > > >>>>>> which one we are talking about when we say "use for reduce"
>>>>>> > > >>>>>>
>>>>>> > > >>>>>>
>>>>>> > > >>>>>> On Mon, 20 Dec 2021 19:11:54 +0100
>>>>>> > > >>>>>> José Valim < jose....@dashbit.co > wrote:
>>>>>> > > >>>>>>
>>>>>> > > >>>>>> > Hi everyone,
>>>>>> > > >>>>>> >
>>>>>> > > >>>>>> > This is the second proposal for-let. You can find it in a
>>>>>> > > >>>>>> > gist:
>>>>>> > > >>>>>> > https://gist.github.com/josevalim/fe6b0bcc728539a5adf9b2821bd4a0f5
>>>>>>
>>>>>> > > >>>>>> >
>>>>>> > > >>>>>> > Please use the mailing list for comments and further
>>>>>> > > >>>>>> > discussion. Thanks for all the feedback so far!
>>>>>> > > >>>>>> >
>>>>>> > > >>>>>>
>>>>>> > > >>>>>> --
>>>>>> > > >>>>>> 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 elixir-lang-co...@googlegroups.com.
>>>>>> > > >>>>>> To view this discussion on the web visit
>>>>>> > > >>>>>> https://groups.google.com/d/msgid/elixir-lang-core/61c0d119.1c69fb81.af520.c181SMTPIN_ADDED_MISSING%40gmr-mx.google.com
>>>>>>
>>>>>> > > >>>>>> .
>>>>>> > > >>>>>>
>>>>>> > > >>>>> --
>>>>>> > > >>>>> 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 elixir-lang-co...@googlegroups.com.
>>>>>> > > >>>>> To view this discussion on the web visit
>>>>>> > > >>>>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4LOyoAmXULJQo%2BYX4eFVJZJAoYtKHytoHujCS_kJ6AEuA%40mail.gmail.com
>>>>>>
>>>>>> > > >>>>> <
>>>>>> > > >>>>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4LOyoAmXULJQo%2BYX4eFVJZJAoYtKHytoHujCS_kJ6AEuA%40mail.gmail.com?utm_medium=email&utm_source=footer
>>>>>> >
>>>>>> > > >>>>> .
>>>>>> > > >>>>>
>>>>>> > > >>>> --
>>>>>> > > >>> 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 elixir-lang-co...@googlegroups.com.
>>>>>> > > >>>
>>>>>> > > >> To view this discussion on the web visit
>>>>>> > > >>> https://groups.google.com/d/msgid/elixir-lang-core/CACzMe7aXBL1jNM_aWmJJzYOjrK%3Dtf-4%2BLPLJLpccu_G4zr0cAg%40mail.gmail.com
>>>>>>
>>>>>> > > >>> <
>>>>>> > > >>> https://groups.google.com/d/msgid/elixir-lang-core/CACzMe7aXBL1jNM_aWmJJzYOjrK%3Dtf-4%2BLPLJLpccu_G4zr0cAg%40mail.gmail.com?utm_medium=email&utm_source=footer
>>>>>> >
>>>>>> > > >>> .
>>>>>> > > >>>
>>>>>> > > >> --
>>>>>> > > > 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 elixir-lang-co...@googlegroups.com.
>>>>>> > > > To view this discussion on the web visit
>>>>>> > > > https://groups.google.com/d/msgid/elixir-lang-core/c1fea9e2-f47c-4236-812a-431bc7d76d62n%40googlegroups.com
>>>>>>
>>>>>> > > > <
>>>>>> > > > https://groups.google.com/d/msgid/elixir-lang-core/c1fea9e2-f47c-4236-812a-431bc7d76d62n%40googlegroups.com?utm_medium=email&utm_source=footer
>>>>>> >
>>>>>> > > > .
>>>>>> > > >
>>>>>> > >
>>>>>> >
>>>>>>
>>>>>> --
>>>>>> 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 elixir-lang-co...@googlegroups.com.
>>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/61c11ffb.1c69fb81.9b607.f827SMTPIN_ADDED_MISSING%40gmr-mx.google.com
>>>>>> .
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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 elixir-lang-co...@googlegroups.com.
>>>>>
>>>>>
>>>>
>>>>
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4K9WRhyaGpXy8Ds%3DbEq%3DpapgF6w%2BRciB-PY6M6Xe5%2BoFQ%40mail.gmail.com
>>>>> (
>>>>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4K9WRhyaGpXy8Ds%3DbEq%3DpapgF6w%2BRciB-PY6M6Xe5%2BoFQ%40mail.gmail.com?utm_medium=email&utm_source=footer
>>>>> ).
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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 elixir-lang-core+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/elixir-lang-core/1990bd4f-ce14-43cb-958a-5e261a9a3d22n%40googlegroups.com
>>> (
>>> https://groups.google.com/d/msgid/elixir-lang-core/1990bd4f-ce14-43cb-958a-5e261a9a3d22n%40googlegroups.com?utm_medium=email&utm_source=footer
>>> ).
>>>
>>
>>
>>
>>
>>
>>
>> --
>> 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 elixir-lang-core+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elixir-lang-core/CACzMe7aQ5h8UEsKtqW5_rNLQQqjzWt-t4oR_WW8-sRzT808O4w%40mail.gmail.com
>> (
>> https://groups.google.com/d/msgid/elixir-lang-core/CACzMe7aQ5h8UEsKtqW5_rNLQQqjzWt-t4oR_WW8-sRzT808O4w%40mail.gmail.com?utm_medium=email&utm_source=footer
>> ).
>>
>>
>
>
--
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 elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/kxgmled3.ae1de33d-c749-42da-af7e-ea64306fc6db%40we.are.superhuman.com.
