Re: Copyright assignment

[Eshel Yaron <me@eshelyaron.com>]

Axel Forsman <axel@axelf.se> writes:

> Eshel Yaron <me@eshelyaron.com> writes:
>
>> Your conversion maps Erlang atoms to Elisp symbols, and AFAICT it
>> will happily map the atom nil to the symbol nil, while in the other
>> direction (Elisp to Erlang), nil is mapped to the empty list.  That
>> means that the Erlang improper list [foo|nil] maps to the proper
>> Elisp list (foo) which then maps to the proper Erlang list [foo].
>
> Yup, I am aware that this is something that will have to be fixed
> eventually.  However, for now I do not foresee it being too much of a
> problem in practice, since, in my experience, nil is not used as an
> atom much in favor of undefined/false/error/etc.
>

Yes, it's probably used less often than those other atoms, but it's
definitely in use: there are quite some uses of the atom nil in the core
Erlang/OTP distribution, as well as in the main Elixir repo, for example.

The problem is that any code that uses the atom nil, whether knowingly
or unknowingly, would potentially run into some tricky issues if it were
to communicate with Emacs via this library.  I think that it's also a
bit hard to fix in a backwards-compatible manner, so I wonder if you
have anything in particular in mind for that eventual fix.  If it's
fixed but it's not backwards-compatible, then any Elisp code that would
rely on this library to communicate with Erlang might have to be
adjusted, for instance because the representation of atoms/symbols would
have to change.

>
> Thanks for taking a look
> Axel