From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eshel Yaron Newsgroups: gmane.emacs.devel Subject: Re: Copyright assignment Date: Sat, 09 Sep 2023 20:57:29 +0200 Message-ID: References: <87ledfmjy4.fsf@axelf.se> <87edj7mdlb.fsf@axelf.se> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4175"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Axel Forsman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 09 20:58:25 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qf3A1-0000rN-48 for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Sep 2023 20:58:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qf39F-0004gG-Us; Sat, 09 Sep 2023 14:57:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qf39E-0004g8-TU for emacs-devel@gnu.org; Sat, 09 Sep 2023 14:57:36 -0400 Original-Received: from mail.eshelyaron.com ([107.175.124.16] helo=eshelyaron.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qf39B-0004a9-IZ for emacs-devel@gnu.org; Sat, 09 Sep 2023 14:57:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1694285852; bh=Pp62hqpZKwZjQj1/gF3BXPhQPDClt/+8T3Ybjdw0I/s=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=DmAwAtLnByltMsy2ZIj11GbFVuShyRhbzMU5dW2fcicrA6r6qd5hOdFhJIWp1jw5U vZn71j4416Il/oR1DWjRTUOt852M83v9jdAszvBGPsPjjXkIUetNwgUX3BfjYKDJYn 8Espqldn6y8H01MfDvo5Ut+/mLpxKfpXfXmwdTUy5rrtjYxsHUrI1FbmsnmdGQohya cmzWvK3rjkiwZSt74mN+9fZhOf9n3pLMOCZf3Tb/fMIDRgzqmItfzdNYPy5R7m62VK +SqnUhnZTcyh1cCOj2dlhnns0y/nyUAKtjPqItu46CG1XTWwdJyMj00Mq6peNNJoLN JGSmcG78YqPMg== In-Reply-To: <87edj7mdlb.fsf@axelf.se> (Axel Forsman's message of "Sat, 09 Sep 2023 18:00:18 +0000 (UTC)") Received-SPF: pass client-ip=107.175.124.16; envelope-from=me@eshelyaron.com; helo=eshelyaron.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:310420 Archived-At: Axel Forsman writes: > Eshel Yaron 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