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.
