Re: [elixir-core:10618] Introduce :let in for-comprehensions

*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

Re: [elixir-core:10618] Introduce :let in for-comprehensions

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

Re: [elixir-core:10616] Introduce :let in for-comprehensions

Hi! I think this is a great idea, after having an initial knee-jerk reaction against it I realized this is actually removing a lot of boilerplate and helps close the gap with imperative languages for some types of algorithms. But indeed, it seems like a potential source of confusion between how

Re: [elixir-core:10615] Introduce :let in for-comprehensions

> > *> let: section_counter <- 1, let: lesson_counter <- 1* > > 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. > Makes sense. If I'm not mistaken it actually means pulling the next

Re: [elixir-core:10615] Introduce :let in for-comprehensions

What about rebinding within a for being more explicit? None of for comprehensions’ existing magic makes me uncomfortable because they’re all either entirely contained in the for declaration, or very explicit in the body (reduce/acc -> ... in the body feels sufficiently explicit). Instead of

Re: [elixir-core:10613] Introduce :let in for-comprehensions

I love this example. I am training new Elixir users in LiveView and OTP, and there are a few burs that don't overly taint Elixir, but could smooth the learning process. This is one of them. One of the techniques I teach is naming concepts, and this is a great opportunity to name a concept. Big

Re: [elixir-core:10612] Introduce :let in for-comprehensions

Thanks everyone, I am discarding the proposal for now and I will resubmit a new one next week. At this point, it is clear the "imperative assignment" is a big departure and any new proposal must not include that. Just one last point. Let's change the Pythagorean Triplets example to store values

Re: [elixir-core:10611] Introduce :let in for-comprehensions

How about this: for section <- sections, let: section_counter <- 1, let: lesson_counter <- 1 do lesson_counter = if section["reset_lesson_position"], do: 1, else: lesson_counter {lessons, lesson_counter} = for lesson <- section["lessons"], let: lesson_counter <-

Re: [elixir-core:10610] Introduce :let in for-comprehensions

I think the `let` feature might have a big impact on the way that people write code in Elixir. I don't know if that will be positive or negative. I lean more toward expecting it to not be great. It feels more imperative. Like setting a variable before a `for` loop in Java, C, ... That all said I

Re: [elixir-core:10609] Re: Introduce :let in for-comprehensions

> Have you run this by anyone you know that hasn’t really used the language? I’d be very interested to get the opinion of someone that doesn’t have any preconceived notions of what fits or doesn’t in Elixir, and can evaluate what option is easiest to learn. I did discuss this during the Twitch

Re: [elixir-core:10608] Introduce :let in for-comprehensions

I was skeptical at first as well until I started thinking more about how convoluted some scenarios are today, and I think we on this mailing list especially are all likely a bit stuck in our ways. If you think about it from the beginner perspective, there is a ton of ceremony for certain

Re: [elixir-core:10607] Re: Introduce :let in for-comprehensions

I just want to +1 what Louis has said. Overall, this feels like it makes things more complex rather than less, particularly because of the limited scope that the feature applies to, which makes it difficult to fit into one’s intuition as they learn the language. While the original example is

Re: [elixir-core:10606] Re: Introduce :let in for-comprehensions

> They would both be unable to use their pre-existing understanding of mutable variables (as the rules are very different), and there would be another set of rules to learn that do not exist elsewhere in Elixir. My hunch is that this feature is one for power-users, not one for newcomers. Perfect,

Re: [elixir-core:10605] Re: Introduce :let in for-comprehensions

Heya > Put yourself into the shoes of someone starting with Elixir and having to solve this problem. How many concepts do you have to learn to get this (allegedly simple) task done? This is the point of view from which I wrote my email- I think this proposal increases the amount of knowledge a

Re: [elixir-core:10603] Feature request: Working directory independent way to get formatter configuration for a file

Oh, the file_server is locally registered and not per process, I don't think we change this. :( On Thu, Dec 16, 2021 at 7:20 PM José Valim wrote: > > So I would like to request that there be a function to get the formatter > options (and as-of Elixir 1.13 formatter as well) relative to a passed

Re: [elixir-core:10603] Feature request: Working directory independent way to get formatter configuration for a file

> So I would like to request that there be a function to get the formatter options (and as-of Elixir 1.13 formatter as well) relative to a passed in directory. If we can settle on an approach I'd be willing to create a PR for this. Maybe I am oversimplifying this but can we: 1. Accept cwd as an

Re: [elixir-core:10602] Re: Introduce :let in for-comprehensions

Hi everyone, Thanks for the input so far. I have one favor to ask: could everyone please think carefully about the problem statement? Put yourself into the shoes of someone starting with Elixir and having to solve this problem. How many concepts do you have to learn to get this (allegedly

[elixir-core:10601] Feature request: Working directory independent way to get formatter configuration for a file

Hi all, While working on ElixirLS we cannot use the normal `mix format` for a few reasons: - We want to provide the results of the formatting as Language Server Protocol edits which allows editors to undo the formatting - We want to format quickly without paying the cost of the BEAM startup time

[elixir-core:10601] Re: Introduce :let in for-comprehensions

I am with Louis and Paul so far I think. I won't repeat their comments but I think I can extend the issue by pointing out that this breaks refactoring for the inner contents of `for`. Previously, if you have: ``` for lesson <- section["lessons"], reduce: 0 do counter -> # complex

Re: [elixir-core:10599] Introduce :let in for-comprehensions

I do not have any issues with the existing syntax as well. I don’t think `let:` is somewhat I am going to use on daily basis, but I also don’t see any harm while the old syntax for `reduce` stays. While we are on topic, I’d share another thing I really miss in `for` comprehensions: early returns

Re: [elixir-core:10598] Introduce :let in for-comprehensions

My gut reaction is the same as Louis'. Looking at the problem statement, the solution, to me, is ultimately a map over the array. The only "problem" is maintaining some state between elements, which is managed well with the map_reduce. All the proposed variations just seem "overworked" to me --

Re: [elixir-core:10597] Introduce :let in for-comprehensions

Heya My initial impression is that this is quite a large departure from the semantics of all other constructs in the language, and the usual rules for reading Elixir no longer apply. The "return value" of a loop block is no longer the final line of the block, it could be spread throughout it. To

[elixir-core:10596] Introduce :let in for-comprehensions

Note: This proposal contains images and rich text that may not display correctly in your email. If so, you can read this proposal in a gist . There is prior art in languages like Common Lisp, Haskell, and even in C# with LINQ on