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.va...@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 <christheke...@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-core+unsubscr...@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-core+unsubscr...@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/CANnyohYUEw-4M25o8iFxrs7Yxd7TjK8cqN3RiJArXZz132ZVWg%40mail.gmail.com.
