There's at least one type of lambda missing from your paper, the OCaml function. After using the keyword `function`, you can directly go into a match:
let toto = function
| 0 -> 'a'
| _ -> 'b'
About the contents of the paper, I'm not sure that I agree with you. There is a clear distinction between lambdas with shorthands and lambdas with named parameters, and I think it exists for a good reason. You seem to base your reasoning on the following:
> The number of symbols is a fundamental aspect of code readability (Tashtoush et al., 2013). In general, the shorter and more compact the code, the higher the code readability factor. Therefore, the perfect lambda syntax makes lambda expressions more readable and improves code editability factor (Blow, 2014) allowing programmers to be more productive in their work.
I'm not convinced that it's true. From the abstract of Tashtoush et al., 2013:
> The survey responses were analyzed using SPSS statistical tool. Most of proposed code features showed to have significantly positive impact on enhancing readability including: meaningful names, consistency, and comments. On the other hand, fewer features such as arithmetic formulas, nested loops, and recursive functions showed to have a negative impact.
That doesn't seem to agree with what you said. Also:
> In general, the shorter and more compact the code, the higher the code readability factor.
I'm not sure where that comes from, but I'm also not convinced that it's true. Try limiting yourself to only one or two characters for name and you will quickly discover that it's probably not generally true.
As an aside, is this a common thing in academia to call something "perfect"? I personally find it weird and even a bit unprofessional but maybe I'm not used to how people talk in papers.
Edit: after thinking about it a bit more, I found why I don't like the type of lambda you proposed. In programming, a lot of people (me included) have the belief that you should be able to sometimes only know the interface of something, not the implementation behind it. Naming your parameters properly is a way to separate that interface and that implementation. Both "sides" agree on what is exchanged, and part of that "contract" is in the name of the parameters.
However, as with all things, there are trade-offs. Sometimes you don't need a strong separation between the two. Lambda expressions are often used in that case: you don't name the function, as you're the one directly using it. However, just because you don't name the function doesn't mean you also don't want to name the parameters, at least all the time. The name of the parameters are often an important part of an interface: the interface of the higher order function you are using. I often use reduce or fold, in a wide variety of language, and I always have trouble remembering if the accumulator is the first or the second parameter of the function I'm passing to reduce. But when I read code that use "acc" and "el", it's very easy to see which is which.
All of that to say that your perfect lambda syntax seems to be a small improvement over the existing positional lambda, and doesn't replace lambdas with named parameters, that have a place. Elixir has both anonymous functions with named parameters and anonymous functions with positional parameters. Both have their use. Example taken from https://elixirschool.com/en/lessons/basics/functions/:
sum = fn (a, b) -> a + b end
sum.(2, 3)
sum = &(&1 + &2)
sum.(2, 3)