Hi Zach,
I recommend trying out your approach on the original problem. You will see
that you will need to accumulate elements, add Enum.reverse/1, etc. All
which will make the solution noisier.
On Fri, Dec 17, 2021 at 6:59 PM Zach Daniel <zachary.s.dan...@gmail.com>
wrote:
> I may not fully be understanding what we're looking for here, but it seems
> like this would effectively be the equivalent of:
>
> ```
> result =
> for foo ← [1, 2, 3], reduce: %{acc: [], counter: 0} do
> %{acc: acc, counter: counter} ->
> new_acc = some_calc(acc)
> %{acc: new_acc, counter: counter + 1}
> end
>
> actual_result = result.acc
> ```
>
> I'm wondering if we could just introduce an additional `state` that you
> match on, and return as a tuple from the for loop body? I think this is
> similar to what the original proposal wanted, but it involves only knowing
> that if you use the `state` option, you need to return a tuple of the for
> loop result and the new state. And it looks similar to a genserver in that
> regard, which makes it feel reasonably conventional.
>
> ```
> result =
> for foo ← [1, 2, 3], reduce: [], state: %{counter: 0} do
> acc, state →
> {some_calc(acc, state.counter), %{state | counter: state.counter + 1}}
> end
> ```
>
>
> Sent via Superhuman <https://sprh.mn/?vip=zachary.s.dan...@gmail.com>
>
>
> On Fri, Dec 17, 2021 at 10:35 AM, João Pedro Evangelista <
> evangelistajo...@gmail.com> wrote:
>
>> *> In fact, making special-semantics different syntactically to be more
>> googleable *
>>
>> Also more easily scannable while reading the code, we would know that
>> this variable has more meaning among the other ones
>> On Friday, December 17, 2021 at 9:32:18 AM UTC-3 christ...@gmail.com
>> wrote:
>>
>>> *> I did consider introducing (precisely) $ for variables but my concern
>>> is that, by introducing special syntax, I believe most would expect it to
>>> be fully mutable, so you can modify it from any scope.*
>>>
>>> I am not sure if I can envision a way to allow imperative-ish variables
>>> without introducing special semantics. So I feel like supporting the new
>>> semantics with special syntax would allow us to set correct expectations
>>> about its scope and mutability when introducing/documenting it!
>>>
>>> In fact, making special-semantics different syntactically to be more
>>> googleable is a perk over plain variables in my mind. For example,
>>> searching *"ruby double at"* (a comparatively oblique ruby language
>>> identifier feature, *@@class_variables*), returns an appropriate top
>>> result
>>> <https://stackoverflow.com/questions/5890118/what-does-variable-mean-in-ruby>
>>> (from an incognito browser session, no less)! So maybe an *"elixir
>>> dollar variable" * google search is a reasonable standard to hold
>>> ourselves to.
>>>
>>> On Friday, December 17, 2021 at 5:40:14 AM UTC-5 sabi...@gmail.com
>>> wrote:
>>>
>>>> Indeed this doesn't address the issue of the level of nesting, and is
>>>> confusing in this case.
>>>>
>>>> The new syntax could maybe include the level of nesting information
>>>> somehow, e,g. `* $section_counter*` in the parent loop, `*
>>>> $$section_counter*` in the child loop...?
>>>> Or *$1.section_counter = 1 *(parent),* $2.section_counter = 1 *(child)?
>>>> (slightly
>>>> inspired by &1)
>>>> *.*
>>>>
>>>> Another way to deal with this inconsistency could be to forbid nested
>>>> comprehension with variables, and require to extract as a new function (in
>>>> the same way the & cannot be nested and require to use fn).
>>>> Most examples would probably be easier to understand this way anyway,
>>>> but this might limit the power of the feature.
>>>>
>>>> Or maybe just having the compiler raising an error if trying to
>>>> re-assign within a nested block, with a helpful beginner-friendly message,
>>>> could be enough to clear this confusion?
>>>> I think this is not so much harder to figure than the fact than a
>>>> re-assignment within an *if* doesn't work as in imperative languages.
>>>>
>>>> By looking at the examples here, I feel that the last one might be the
>>>> most elegant of these 3 ideas:
>>>> https://gist.github.com/sabiwara/97c480c2076666ba9b98cf7a142a5a0f
>>>>
>>>>
>>>> Le ven. 17 déc. 2021 à 16:14, José Valim <jose....@dashbit.co> a
>>>> écrit :
>>>>
>>>>> *Re: for section <- sections, $section_counter = 1, $lesson_counter =
>>>>> 1 do*
>>>>>
>>>>> I did consider introducing (precisely) $ for variables but my concern
>>>>> is that, by introducing special syntax, I believe most would expect it to
>>>>> be fully mutable, so you can modify it from any scope. That's why I
>>>>> decided to go with plain variables, because they already have a limited
>>>>> scope in Elixir and clear rules (but at the same time I agree that adding
>>>>> :let would make those clear rules precisely more confusing!).
>>>>>
>>>>> On Fri, Dec 17, 2021 at 7:01 AM Christopher Keele <christ...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I love the thought put into this proposal, and really like the
>>>>>> problem it is tackling! I am looking forward to the next proposal and
>>>>>> will
>>>>>> try to get to my inbox earlier for it.
>>>>>>
>>>>>> *Proposal Feedback*
>>>>>>
>>>>>> I mostly second the impressions voiced here, but *really* want to
>>>>>> call attention to the criticism:
>>>>>>
>>>>>> *> this breaks refactoring for the inner contents of `for`*
>>>>>>
>>>>>> This is the real true deal-breaker for me. Referential transparency
>>>>>> is a huge part of my mental model of Elixir and the key reason why it is
>>>>>> such a joy to maintain code in. I am not sure if it is possible to
>>>>>> introduce an imperative-loop construct that *doesn't* violate this
>>>>>> property, so I may have to get over that. I do remember how painful it
>>>>>> was
>>>>>> to remove assignment-inside-ifs, though.
>>>>>>
>>>>>> *Replies*
>>>>>>
>>>>>> *Re: **for section <- sections, $section_counter = 1,
>>>>>> $lesson_counter = 1 do*
>>>>>>
>>>>>> *> Maybe a possibility could be to distinguish comprehension
>>>>>> variables, for example by prefixing them in the same way as module
>>>>>> attributes are prefixed with `@`.*
>>>>>>
>>>>>> This does elegantly solve my refactoring concern; in that
>>>>>> "imperative" comprehension variables copied out of the comprehension
>>>>>> could
>>>>>> immediately raise a syntax error, as would moving them into a different
>>>>>> comprehension that does not have them declared as imperative in the
>>>>>> comprehension head. The compiler would also have to enforce never letting
>>>>>> you use the same name with an imperative variables as with a normal one,
>>>>>> to
>>>>>> completely eliminate edge cases. I think this solution even works for
>>>>>> nested comprehensions, though I still am not sure how *that* would
>>>>>> work with the existing proposal.
>>>>>>
>>>>>> *> We could maybe even remove the `let` keyword altogether?*
>>>>>>
>>>>>> *That * makes me really like syntax. We are not exactly running
>>>>>> short on propositions but it nice to keep that overhead low. Also, the
>>>>>> only
>>>>>> other existing identifier syntax (module attributes) use a prefix/sigil
>>>>>> approach as well, and this feels in the same category to me: we are
>>>>>> introducing a different type of identifier with different scoping rules
>>>>>> (even though what happens at compile time to it is wildly different).
>>>>>>
>>>>>> *Re: **overloading the **<- operator*
>>>>>>
>>>>>> *> My concern about this is that `<-` in for means extracting
>>>>>> something from the collection, so giving it another meaning inside an
>>>>>> option can be quite confusing.*
>>>>>>
>>>>>> *> If I'm not mistaken it actually means pulling the next item from
>>>>>> an enumerable.*
>>>>>>
>>>>>> FWIW I've been writing Elixir for years and I still forget when I
>>>>>> crack open a *for* or for a *with* that I need to be using *<-* .
>>>>>> I've just internalized it as the "powerful SpecialForms clause operator".
>>>>>> So I don't think allowing its use in other powerful new constructs,
>>>>>> potentially nested in *for* or *with*, or inside their options
>>>>>> lists, would be confusing, from my perspective at least.
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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/72ee4929-efde-476e-9124-bacd7460c486n%40googlegroups.com
>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/72ee4929-efde-476e-9124-bacd7460c486n%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/CAGnRm4%2BsbvBxoj1mECXzBna%3DJE-R8%2Bj-CBuRZvgAf%2BsLp2aMjw%40mail.gmail.com
>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BsbvBxoj1mECXzBna%3DJE-R8%2Bj-CBuRZvgAf%2BsLp2aMjw%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/10d18915-55da-4b52-8e12-0992625039e3n%40googlegroups.com
>> <https://groups.google.com/d/msgid/elixir-lang-core/10d18915-55da-4b52-8e12-0992625039e3n%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/kxaott2e.e380bedb-a7bd-4f10-8d2c-573d453c6880%40we.are.superhuman.com
> <https://groups.google.com/d/msgid/elixir-lang-core/kxaott2e.e380bedb-a7bd-4f10-8d2c-573d453c6880%40we.are.superhuman.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/CAGnRm4KYBajtuG0sAA%2BOtaWDo8AKn5csz6irK3f-Y1BLmrqvbw%40mail.gmail.com.
