*> 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 >> >> >> 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/10d18915-55da-4b52-8e12-0992625039e3n%40googlegroups.com.
