5 ms·

The main problem with them in Elixir is that you can't pattern match on keyword arguments without imposing an arbitrary order.

by foldr 3y ago

sph 3y ago
Of course, they're linked list, they have an inherent order. Once you understand how they behave, you understand where the abstraction leaks.
- foldr 3y ago
  Yes, I understand why this is the case. However, it is still a mild annoyance that you cant (sensibly) write e.g. def foo(x, opt1: opt1, opt2: opt2) If optional arguments were first-class citizens in the language, then you'd presumably be able to use patterns along these lines.
  - sph 3y ago
    I get that. But it's built on top of the Erlang VM, neither Erlang nor it's VM support these. All languages have their own leaky abstractions, and stuff that should in theory work, but doesn't.
  - josevalim 3y ago
    It is unfortunately much trickier because keyword lists are also optional. So what happens if opt2 is not given? We could raise but... since they are optional, we wouldn't want it to raise but rather have a default value. Of course, we could then say "let's allow a default value to be given when pattern matching keyword lists". The problem is that no other pattern works like this and it would be inconsistent. I think optional arguments are fundamentally incompatible with pattern matching (in Elixir). I understand why we would want that but, if we did have it, we would be adding tons of complexity and it would stand out as a sore thumb. I am also wary of going towards the same direction as Ruby and Python which have quite complex argument handling (albeit we have slightly different feature sets).
    - di4na 3y ago
      I think there is a possible design for them that is not too bad, but it would need named parameters. I think the time o encountered that idea was part of a longer post about solving a different problem in Rust. But i doubt it would be an urgent thing to change. Tldr: add named arguments (optional). You can call with anon names, in which case it is positional as it is today. If you use named arguments to call, you have to use them in the order they have been declared, just like with positional, but you _can_ omit some. These get the default value. There are ofc combinations that could be allowed, like anon until the first optional one, whatever. It was part of this post, but don't it was a solution to a different problem kinda (and kinda not technically) https://faultlore.com/blah/defaults-affect-inference/ https://faultlore.com/blah/defaults-affect-inference/
sodapopcan 3y ago
--DELETED-- I said suggested you could pattern match on keyword lists with guards but that isn't true—I should not respond to things first thing in the morning.
- foldr 3y ago
  I mean pattern matching in the sense of binding a variable to each option.

The main problem with them in Elixir is that you can't pattern match on keyword arguments without imposing an arbitrary order.

by foldr 3y ago

The main problem with them in Elixir is that you can't pattern match on keyword arguments without imposing an arbitrary order.

sph 3y ago

Of course, they're linked list, they have an inherent order. Once you understand how they behave, you understand where the abstraction leaks.

foldr 3y ago
Yes, I understand why this is the case. However, it is still a mild annoyance that you cant (sensibly) write e.g. def foo(x, opt1: opt1, opt2: opt2) If optional arguments were first-class citizens in the language, then you'd presumably be able to use patterns along these lines.
- sph 3y ago
  I get that. But it's built on top of the Erlang VM, neither Erlang nor it's VM support these. All languages have their own leaky abstractions, and stuff that should in theory work, but doesn't.
- josevalim 3y ago
  It is unfortunately much trickier because keyword lists are also optional. So what happens if opt2 is not given? We could raise but... since they are optional, we wouldn't want it to raise but rather have a default value. Of course, we could then say "let's allow a default value to be given when pattern matching keyword lists". The problem is that no other pattern works like this and it would be inconsistent. I think optional arguments are fundamentally incompatible with pattern matching (in Elixir). I understand why we would want that but, if we did have it, we would be adding tons of complexity and it would stand out as a sore thumb. I am also wary of going towards the same direction as Ruby and Python which have quite complex argument handling (albeit we have slightly different feature sets).
  - di4na 3y ago
    I think there is a possible design for them that is not too bad, but it would need named parameters. I think the time o encountered that idea was part of a longer post about solving a different problem in Rust. But i doubt it would be an urgent thing to change. Tldr: add named arguments (optional). You can call with anon names, in which case it is positional as it is today. If you use named arguments to call, you have to use them in the order they have been declared, just like with positional, but you _can_ omit some. These get the default value. There are ofc combinations that could be allowed, like anon until the first optional one, whatever. It was part of this post, but don't it was a solution to a different problem kinda (and kinda not technically) https://faultlore.com/blah/defaults-affect-inference/ https://faultlore.com/blah/defaults-affect-inference/

sodapopcan 3y ago

--DELETED-- I said suggested you could pattern match on keyword lists with guards but that isn't true—I should not respond to things first thing in the morning.

foldr 3y ago
I mean pattern matching in the sense of binding a variable to each option.