Yes, I just rebind in that case…
kokolegorille
Sanjibukai
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..)
0
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
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.
3
Sanjibukai
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..
0
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
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.
5
Sanjibukai
Well I missed that!
You’re totally right and it even makes total sense!
Thank you for this precision!
1
ar7max
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
0
LostKobrakai
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
2