Information loss with current variable name binding model (JSON -> Json) about livebook

[josevalim]

Thank you for the report. Maybe we will need to keep a mapping in the evaluator to know how to handle those. I also can't think of alternatives. :(

[nixxquality]

Perhaps instead of keeping a list of bindings by name only, you could keep them with their original name and a tag suggesting an origin, which can be converted when necessary.
An example, in Erlang terms, would be:

Bindings = [{erlang, Name}, ...].

to_erlang_var({erlang, Name}) -> Name;
to_erlang_var({elixir, Name}) -> to_camel_case(Name).

[jonatanklosko]

Good catch. There is more to it, the current conversion maps JsON and JsOn to the same Elixir name, so if both names were to be defined it can actually break the semantics.

I think we really need an unambiguous mapping. My vote is to convert JSON to j_s_o_n, this is not pretty, but only matters if the user writes both Erlang and Elixir. Besides, one may argue the variable should be Json anyway :) @josevalim wdyt?

[josevalim]

I think we don’t need to worry about multiple Elixir vars converting to the same Erlang one, that’s fine. Just change your Elixir var name. But Erlang vars should go back and forth without issues.

[jonatanklosko]

Just change your Elixir var name.

Ideally we should not have conflicts in the conversion, I think that's confusing.

My point is that with an unambiguous mapping we achieve both and it seems like the simplest approach.

There are a couple more cases, because technically Erlang env vars can also have underscores. But I think the following would be unambiguous (same procedure both ways):

1. Toggle the first char case
2. _x <-> X

And this results in:

Erlang <-> Elixir

# Usual
Json <-> json
JSON <-> j_s_o_n
JsOn <-> js_on
JsON <-> js_o_n

# Mostly irrelevant edge cases
J_s_o_n <-> jSON
Js__on <-> js_On
Js__o_n <-> js_ON
JsO_N <-> js_oN
Js_on <-> jsOn

[josevalim]

regardless of what I said, that’s by far the simplest option, so I agree. :)