*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.
