[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Copyright assignment
From: |
Axel Forsman |
Subject: |
Re: Copyright assignment |
Date: |
Mon, 11 Sep 2023 17:38:43 +0000 (UTC) |
Eshel Yaron <me@eshelyaron.com> writes:
> 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.
(Many uses in OTP are for using an atom to indicate [],
or will not otherwise be returned from RPC calls in normal usage.
But it is a poor excuse for not fixing the caveat.)
> 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.
I pushed the fix I had in mind in commit df6d8a7 [1].
It would also be neat to make the representation configurable,
similar to what most JSON libraries in dynamically-typed languages do,
but that is very low on my list of priorities.
[1]:
http://url8156.axelf.se/ls/click?upn=OEjhiLt4EQwBP7BMdu61cV4sca9Texj-2F9QlDxDS4hNAJQRktQfhHyVAjxWE-2BxYhD6rzUsQ-2FhslJnmq6RI2SMvRnuyJ-2FNrEFQELYje065Rxl-2FgrssbC-2BOXwN22MiOjir-2Fp2UQ_1I2drHf7TOM-2BFjFYSrHxnLAP9jSFTsULAwXlGneTUPL4uZsQNqQtWWrZN-2Bl8JiQSq9wapel4vlP7IOIPq4cZmME5x8VXuna0nj7xxySKqYB6S3FsLUceFImsD-2FDvpzUOb7PJrWF7n7-2BtnzBBogLzTds9oBy7seiURzURMAhmI38IR-2BDY2vMjYFz-2Bl2VTTq0JTrGDlIkBvo5sYkQYW7aHlw-3D-3D
/Axel