Oh, and if you don't have `reduce` then it just becomes the first thing, e.g
```
for foo ← [1, 2, 3], state: %{counter: 0} do
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 12: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 < evangelistajoaop@
> gmail. com ( 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
>>>> ( 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+unsubscribe@ googlegroups. com (
>> 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/kxap51gd.a89f3bd3-f6d5-4440-bdcf-74f6c3fb1a52%40we.are.superhuman.com.
