This is so important, not on a case by case basis but in aggregate. -bt
On Fri, Aug 23, 2024 at 6:20 PM José Valim <jose.va...@dashbit.co> wrote: > It is ambiguous in the sense it now requires context. when I see &2, I > will no longer know what it means without also analyzing its surrounding > context. It means that every time I scan &2 in a line, I need to think > which one of its two uses is being applied. > > On Fri, Aug 23, 2024 at 23:53 Ivan Yurov <ivan.your...@gmail.com> wrote: > >> I agree it's controversial, but it's certainly not too short: here's the >> example of how Scala does it >> https://docs.scala-lang.org/scala3/book/fun-anonymous-functions.html, if >> I remember correctly Haskell has something like that as well, but it might >> be powered by currying, so not exactly related to lambda notation. >> >> Can you give some examples of where it could be ambiguous, please? I >> agree that declaring arity explicitly along the introductory & might be >> cumbersome (yet if it's optional, then no harm to existing code is done), >> but how about zero argument lambdas? I understand that &1 would be >> ambiguous, but &(1) wouldn't. Or am I missing something? Perhaps other >> special uses of &? >> >> On Thu, Aug 22, 2024 at 11:16 PM José Valim <jose.va...@dashbit.co> >> wrote: >> >>> Thank you for the proposal. >>> >>> Some would already say the capture syntax is already too concise (and >>> they would always prefer fn instead), and the proposal would introduce >>> ambiguity to them, given that &2 would have different meanings depending on >>> where it is located. One of the big rules in Elixir is that, when we give >>> syntax affordances, such as the capture operator, we keep its usage rules >>> clear and this extension would violate that (in my opinion). >>> >>> On Fri, Aug 23, 2024 at 8:06 AM Ivan Yurov <ivan.your...@gmail.com> >>> wrote: >>> >>>> The lambdas I want to be able to create using short notation are in the >>>> second block of code in the original posting. They are slightly less >>>> obvious than & &1 + 1. >>>> As far as I understand, there's no way to compose them using short >>>> form, unless I'm missing something. The idea to supply a number of >>>> arguments along with introductory & is probably not gonna fly — it would >>>> look too similar to argument itself, although there shouldn't be any >>>> ambiguity with parsing since nested short form lambdas are not allowed >>>> anyways. Maybe &/2 which would be consistent with captures? >>>> >>>> >>>> On Thu, Aug 22, 2024 at 10:19 AM Ben Wilson <benwilson...@gmail.com> >>>> wrote: >>>> >>>>> Hey Ivan, >>>>> >>>>> You're just missing the introductory & >>>>> >>>>> iex(1)> & &1 + 1 >>>>> #Function<42.105768164/1 in :erl_eval.expr/6> >>>>> >>>>> On Wednesday, August 21, 2024 at 2:03:24 AM UTC-4 ivan.y...@gmail.com >>>>> wrote: >>>>> >>>>>> I realize it might be controversial, but I truly enjoy short form >>>>>> lambdas in any language I touch and Elixir is one of them. Yet I think >>>>>> there's a couple of use cases that are uncovered. One is when you need to >>>>>> encode a zero argument lambda returning a value and the second one is >>>>>> when >>>>>> there are more arguments than actually used: >>>>>> >>>>>> iex(1)> &(&2 + 1) >>>>>> >>>>>> error: capture argument &2 cannot be defined without &1 (you cannot >>>>>> skip arguments, all arguments must be numbered) >>>>>> >>>>>> └─ iex:1 >>>>>> >>>>>> >>>>>> ** (CompileError) cannot compile code (errors have been logged) >>>>>> >>>>>> >>>>>> iex(1)> &(1) >>>>>> >>>>>> error: capture argument &1 must be used within the capture operator & >>>>>> >>>>>> └─ iex:1 >>>>>> >>>>>> >>>>>> ** (CompileError) cannot compile code (errors have been logged) >>>>>> >>>>>> I think both of these cases would be handled if we let explicitly >>>>>> defining the arity of lambda: &2(&2 + 1) or something like that. Since >>>>>> nested lambdas are not allowed anyways, this should work (unless I'm >>>>>> missing something). And we'd assume if there's no access to the >>>>>> variables, >>>>>> it would be a zero argument function, so &(1) would work too. >>>>>> >>>>>> This should be fundamentally possible, since I can do this: >>>>>> >>>>>> iex(9)> fn () -> :ok end >>>>>> >>>>>> #Function<43.105768164/0 in :erl_eval.expr/6> >>>>>> >>>>>> iex(10)> fn (_a, b) -> b * 2 end >>>>>> >>>>>> #Function<41.105768164/2 in :erl_eval.expr/6> >>>>>> >>>>>> So I assume it boils down to parsing? Either way, I'd love to see >>>>>> that in Elixir and I'm willing to contribute some time to get it >>>>>> implemented if the community approves it. >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to a topic in the >>>>> Google Groups "elixir-lang-core" group. >>>>> To unsubscribe from this topic, visit >>>>> https://groups.google.com/d/topic/elixir-lang-core/g2tQI1FjcNU/unsubscribe >>>>> . >>>>> To unsubscribe from this group and all its topics, 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/11ca2681-4b0e-4875-ac48-455a5e684f6en%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/elixir-lang-core/11ca2681-4b0e-4875-ac48-455a5e684f6en%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> >>>> >>>> -- >>>> Kind regards, >>>> Ivan Yurov >>>> >>>> -- >>>> 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/CAAoaZy4gPokWC7urFA7sjqHzL%3DyVKdkHqGd6PM_Sc5o0MDtVGg%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAAoaZy4gPokWC7urFA7sjqHzL%3DyVKdkHqGd6PM_Sc5o0MDtVGg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "elixir-lang-core" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/elixir-lang-core/g2tQI1FjcNU/unsubscribe >>> . >>> To unsubscribe from this group and all its topics, 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/CAGnRm4K9SLYYFOU0dPAQ0uqAc7ms4Dq%2B8gPfX4Y0zY9uHJ4Frg%40mail.gmail.com >>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4K9SLYYFOU0dPAQ0uqAc7ms4Dq%2B8gPfX4Y0zY9uHJ4Frg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >> >> >>> >> >> -- >> Kind regards, >> Ivan Yurov >> >> -- >> 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/CAAoaZy7-w%2BvyWY9t6v03wrfyMfc4XKy1UyEs0K7AtEedEGt5sQ%40mail.gmail.com >> <https://groups.google.com/d/msgid/elixir-lang-core/CAAoaZy7-w%2BvyWY9t6v03wrfyMfc4XKy1UyEs0K7AtEedEGt5sQ%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/CAGnRm4KBLEF9umPV9dQpeQEgFnOoTGmXo%3DM0MfaTFfO4eg-54Q%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KBLEF9umPV9dQpeQEgFnOoTGmXo%3DM0MfaTFfO4eg-54Q%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- Regards, Bruce Tate CEO <https://bowtie.mailbutler.io/tracking/hit/f8218219-d2a8-4de4-9fef-1cdde6e723f6/c7c97460-016e-45fb-a4ab-0a70318c7b97> Groxio, LLC. 512.799.9366 br...@grox.io grox.io -- 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/CAFXvW-7oF6mT%3DHhYjgCNwAxK%3D%3D%3DXDwS%2BCMfjAhgwKQZXBVR-Og%40mail.gmail.com.
