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
regular variables and comprehension variables behave.
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 could also solve the issue of keyword lists having plain atom keys and
not carrying context.
{sections, _} =
for section <- sections,
let: [$section_counter: 1, $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 do
lesson = Map.put(lesson, "position", $lesson_counter)
$lesson_counter = $lesson_counter + 1
lesson
end
section =
section
|> Map.put("lessons", lessons)
|> Map.put("position", $section_counter)
$section_counter = $section_counter + 1
section
end
We could maybe even remove the `let` keyword altogether?
for section <- sections, $section_counter = 1, $lesson_counter = 1 do
(and it this case would be returning a tuple of 3 for instance).
There are probably a lot of downsides I don't see, and it introduces a
change in the language syntax, which might not be justified by this use
case.
Cheers
Le ven. 17 déc. 2021 à 07:17, José Valim <jose.va...@dashbit.co> a écrit :
> 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 in Map. We can do this:
>
> for a <- 1..20,
> b <- 1..20,
> c <- 1..20,
> a*a + b*b == c*c,
> reduce: %{} do
> acc -> Map.put(acc, {a, b}, c)
> end
>
> The whole "reduce: %{} do acc ->" is a construct that you have to learn
> and, although it plays by the language syntax rules, it is quite specific
> to "for". Maybe your answer is, "that's why I don't use for", but that's
> partially the point: we already have for, it has its own rules, but they
> are verbose, not frequently used, while still having a lot of potential
> inside them. As much potential as "for" in most languages.
>
> How can we teach someone how to do a map_reduce without telling them about
> map_reduce? I don't believe it is possible today without this additional
> cognitive load. You do need to learn where it comes from at some point, but
> we don't learn how to paint by first learning the name of all colors.
>
> Some more replies below (quotations in bold).
>
> *> 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.
>
> *> for {k, v} <- Enum.reverse(list), reduce: acc: %{} do*
>
> My very early prototypes (I have been working on this for several weeks
> now) used keyword lists but there is one big issue. Variables in Elixir are
> identified by their name and their context (which is important for variable
> hygienes in macros). A keyword list has atom as keys and they don't carry
> the context, which means we can't use atoms (keys in keyword lists) to
> express variables.
>
> --
> 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/CAGnRm4LmO8v%2BdzAtvNd8Ni%2BmWFgL0R%2B%3Dz-sVntuyp0ow%2BzaH4g%40mail.gmail.com
> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4LmO8v%2BdzAtvNd8Ni%2BmWFgL0R%2B%3Dz-sVntuyp0ow%2BzaH4g%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/CANnyohZxmM7aBjHhm6HPFWgyhY1sJSFiDZ6L%3Dr9sRkom6C68og%40mail.gmail.com.
