About variables scope

cond do
  to_date_time(string) = datatime -> datetime
  to_date(string) = date ->  to_date_time("#{string}T00:00:00+03:00")
  String.contains?(string, "+") -> to_date_time(String.replace(string, "+", "T00:00:00.000+"))
  true -> string
end

Just my 2 cents:

def parsed(string) do
    # some other code here
    #...

    # Problem: I need to parse xml document with multiple broken datetime formats
    #    to_date and to_date_time returns either value or nil
    #
    #    string - source value
    #    value - parsed one

    value = value || to_date_time(string)

    value = value || if to_date(string), do:
      to_date_time("#{string}T00:00:00+03:00")

    value = value || if String.contains?(string, "+"), do:
      String.replace(string, "+", "T00:00:00.000+") |> to_date_time()
    
   value || string
end

I dont like this solution but atm Im ok with it

Well I missed that!

You’re totally right and it even makes total sense!

Thank you for this precision!

What you’re proving is precisely that rebinding isn’t mutability. The function closes over the value of x. That value isn’t changed when you rebind x. If it changed in the function then x is in fact not immutable. Javascript does not have immutability, so it behaves the way you observe. Closures in immutable languages behave the way you observed in Elixir.

Well I was talking about the mechanism provided in closures where the parent scope is still available even the scope happening after the closure definition.

In Elixir the parent scope is available but only the scope until the closure, not after, which is not really a closure then. Or not the one I’ve learned..

For instance in your example x in the parent scope is available in the function but it’s somehow frozen to that moment (with the value of 10). So when x is modified after the function definition (it becomes 2), it’s still available (hence being a closure) but not with its current value (2), only the old one at that moment (10), so the function is not really a closure.

I mean at least closures in JavaScript work like this (but I guess it’s the same for all the other languages when talking about closures).

You can easily try the following in the developer console of you browser (here an example output in Chrome).

>  x=10
<· 10
>  fun = (y) => {return x+y}
<· (y) => {return x+y}
>  fun(4)
<· 14
>  x=2
<· 2
>  fun(4)
<· 6

But I might be wrong since I’m not really a seasoned JS dev and even less a seasoned FP dev..

Anonymous functions are closures:

iex(5)> x = 10
10
iex(6)> fun = fn y ->
...(6)>   y + x
...(6)> end
#Function<7.91303403/1 in :erl_eval.expr/5>
iex(7)> fun.(4)
14
iex(8)> x = 2
2
iex(9)> fun.(4)
14

Note how rebinding the value of x on line iex(8) didn’t change the output of fun. fun closed over the variables it referred to.

Your first example is interesting because it’s the opposite of a closure.
And for a FP language it makes actually total sense (because of side effects free immutability etc.)

But now I’m here is there any closure mechanism in Elixir?

Regarding for example Clojure which is also FP, do they have closures? (I always assumed that the name had something to do with closures..)

Yes, I just rebind in that case…

There’s some nuance to Elixir scoping because what would be “reassignment” in other languages is really more of a “rebinding”:

iex(1)> foo = 123
123
iex(2)> thing = fn -> foo end
#Function<21.126501267/0 in :erl_eval.expr/5>
iex(3)> thing.()
123
iex(4)> foo = 456
456
iex(5)> thing.()
123

The anonymous function in thing captures the value of foo when it’s initially evaluated in the second expression. Subsequent “reassignment” of foo is really rebinding the name, so the anonymous function retains its original reference.

This behavior is intended to be more ergonomic than Erlang, which uses the pattern-matching approach and allows exactly one assignment / binding for a name. In that style, the example above is:

iex(1)> foo1 = 123
123
iex(2)> thing = fn -> foo1 end
#Function<21.126501267/0 in :erl_eval.expr/5>
iex(3)> thing.()
123
iex(4)> foo2 = 456
456
iex(5)> thing.()
123

Written in this style, it’s much more apparent that the second assignment shouldn’t affect the first binding.

TIL that there was the “imperative assignment” in Elixir..

So if I correctly understood, now we have what’s a pattern matching, and a variable binding when a variable is on the left hand side (without the pin ^).. But back then there was an other behavior called “imperative assignment”?