Elixir and misspelled keyword list options

Chat / Discussions
1

A lot of functions in the standard library trod along happily if a misspelled keyword list option is passed:

iex(3)> String.split("a1a11a", "1", triim: true)
["a", "a", "", "a"]

Compare to Python, which has keyword arguments baked into the language:

>>> from sklearn.linear_model import LogisticRegression
>>> LogisticRegression(qwerty=5)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() got an unexpected keyword argument 'qwerty'

The Elixir behavior has bitten me many times. Putting the onus on the developer to check whether options are all valid isn’t working in my opinion, given that these kinds of checks are incredibly rare. One solution is to add a helper function to the standard library:

defaults = [opt: false, another_opt: true, rare_opt: 5]
correct_opts = [opt: true, another_opt: false]

Options.get!(correct_opts, defaults)
# [opt: true, another_opt: false, rare_opt: 5]

misspelled_opts = [blopt: true, another_opt: false]

Options.get!(misspelled_opts, defaults)
# throws, since blopt is not in defaults

This solution is too verbose, I think, since it requires developers to name all options at least once more than they usually would. The reason why this is almost a non-issue in Python is that it would take more effort to allow misspelled keyword arguments. With that in mind, I think the use of macros might be warranted.

def my_fun(positional_arg, opts \\ []) do
  options!(opts, my_opt = false, another_opt = true, rare_opt = 5)
  IO.inspect(rare_opt) # the value passed for opts[:rare_opt]
end

my_fun("pos_arg", my_opt: true)

my_fun("pos_arg", fake_opt: true) # throws

The intended behavior is that of keyword arguments in Python, meaning that the options are accessible as another_opt rather than opts[:another_opt] after the options! macro call.

I don’t necessary like the assignment syntax hijacking, but I do think a solution of this kind is called for.

1 Like
2

This doesn’t need to be a macro, you could implement a function that takes the desired keywords from the list and throws on any unexpected keywords :slight_smile:

1 Like
3

I would find that very annoying during development. Often when playing around, I put a spelling mistake in an optional keyword to temporarily disable it (for fiddling around etc.).

4

I built the library Specify for situations where we want to make explicit what options are supported somewhere (and what defaults are used for them).

As for the behaviour of functions built-in to Elixir: I agree that in many cases it would be preferable for the function to crash rather than to silently ignore an unrecognized keyword. In some cases this currently happens but seemingly not everywhere.

That said, if you were to currently write code like this:

defmodule OptionsExample do
  def foo(normal, arguments) do
    foo(normal, arguments, some_option: true)
  end

  def foo(normal, arguments, some_option: some_option) do
     # ...
     IO.inspect({normal, arguments, some_option})
  end
end

then if we were to call it with OptionsExample.foo(10, 20, unexistent: 42) then we will get a FunctionClauseError that highlights what values were passed as well as which function clauses were attempted:

** (FunctionClauseError) no function clause matching in OptionsExample.foo/3    
    
    The following arguments were given to OptionsExample.foo/3:
    
        # 1
        10
    
        # 2
        20
    
        # 3
        [unexistent: 42]
    
    Attempted function clauses (showing 1 out of 1):
    
        def foo(normal, arguments, [some_option: some_option])

Writing code like this is already a very lightweight way to create the behaviour you are suggesting.

2 Likes
5

That’s only lightweight if a function has 1 option, though, especially since keyword lists are ordered. If a function has 4 options you’d probably need tens of function clauses.

The most radical solution, of course, would be to extend def to deal with parsing options:

  def foo(normal, arguments, !some_option = 5, !other_option = 3) do
     # ...
     IO.inspect({normal, arguments, some_option})
  end

But I think the option! macro I suggested would be sufficient.

6

I stand corrected. :slightly_smiling_face:

7

The NimbleOptions library by Dashbit provides a way to validate Keyword lists by validating the options against a definition. The examples below are from the README.

This library allows you to validate options based on a definition. A definition is a keyword list specifying how the options you want to validate should look like:

definition = [
  connections: [
    type: :non_neg_integer,
    default: 5
  ],
  url: [
    type: :string,
    required: true
  ]
]

Now you can validate options through NimbleOptions.validate/2:

options = [url: "https://example.com"]

NimbleOptions.validate(options, definition)
#=> {:ok, [url: "https://example.com", connections: 5]}

If the options don’t match the definition, an error is returned:

NimbleOptions.validate([connections: 3], schema)
#=> {:error, "required option :url not found, received options: [:connections]"}
3 Likes