*> 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/2903649f-f012-494e-8973-b90d92131713n%40googlegroups.com.
