1. 8
    Function/Variable Ambiguity in Elixir elixir erlang stratus3d.com
    Stratus3D avatar authored by Stratus3D 9 months ago |
    Archive.org Archive.today Ghostarchive
    | 6 comments
  1. 7
    gamache avatar gamache 9 months ago | link

    I agree that José may have made the wrong call here, making parens an optional part of function application. Ruby damage.

    But I disagree that it’s much of a problem in practice:

    • the compiler is more than happy to issue a warning about implicit parens, which this blog post skips over
    • application of a function that is the value of a variable requires a dot, e.g., myfun.() instead of myfun or myfun(), which this blog post does not mention
    • Resolving the question “am I referring to the function or local value?” is a matter of checking what’s in scope, kind of like one would expect in a modern, lexically scoped language
    1. 2
      hauleth avatar hauleth 9 months ago | link

      The thing is that parens-less calls are required for “syntax purposes”, as defining functions as:

      def(x(), do: x)

      Isn’t the most pleasant syntax out there. Then we would end with parentheses everywhere and it would look like M-expressions.

      1. 2
        gamache avatar gamache 9 months ago | link

        That’s a good point. The other way to provide this would be something like reader macros, and I do not find myself wishing we had those around.

    2. 2
      tyoung avatar tyoung 9 months ago | link

      I appreciate the theoretical issue here, but in practice stuff like this would (should?) never pass code review. I’d go so far as to recommend the Credo check to disallow variable rebinding period—if you really want it in a particular file, at least you’d have to opt into it.

      1. 3
        hauleth avatar hauleth 9 months ago | link

        I often use argument shadowing like:

        def foo(a) do
  a = List.wrap(a)

  # Here I can treat `a` as a list, ignoring whether it was such earlier
end

        Alternative is to write it as:

        def foo(a) when is_list(a) do
  # …
end

def foo(a), do: foo([a])

        Or try to find an alternative name for a in the first case. Both of these approaches doesn’t really compels to me.

      2. 1
        wink avatar wink 9 months ago | link

        The erlang example with the var is disingenious because X the variable is different than x the function. Yes, you have to know that variables are uppercase, but you’d hardly make it past day 1 without knowing that.