From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Bytecode interoperability: the good and bad Date: Fri, 22 Dec 2017 09:08:33 -0500 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1513951616 27915 195.159.176.226 (22 Dec 2017 14:06:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 22 Dec 2017 14:06:56 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 22 15:06:52 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eSNyN-0006re-Sq for ged-emacs-devel@m.gmane.org; Fri, 22 Dec 2017 15:06:51 +0100 Original-Received: from localhost ([::1]:51987 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSO0M-0006o1-EW for ged-emacs-devel@m.gmane.org; Fri, 22 Dec 2017 09:08:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37261) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSO0G-0006nN-0O for emacs-devel@gnu.org; Fri, 22 Dec 2017 09:08:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eSO0C-0007aN-Ry for emacs-devel@gnu.org; Fri, 22 Dec 2017 09:08:47 -0500 Original-Received: from [195.159.176.226] (port=52207 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eSO0C-0007Ze-KK for emacs-devel@gnu.org; Fri, 22 Dec 2017 09:08:44 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1eSNyB-00066s-9t for emacs-devel@gnu.org; Fri, 22 Dec 2017 15:06:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 28 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:1L4o4k+zla/mObSYSYwmyf2B9XM= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:221337 Archived-At: > In other kinds of bytecode such as the one for C Python, a bytecode version > number is stored in the bytecode file. When there is a change to the > bytecode, that number is changed. So far, the only changes that have been made to the byte-code language is to add new (previously unused) byte codes. So from this perspective we have always maintained backward compatibility (you can run a .elc compiled with an older Emacs). We do not aim to maintain forward compatibility (so whether a .elc file compiled with a more recent Emacs will work is not guaranteed), although it sometimes does work. When encountering an unknown byte-code, Emacs signals an error, so it shouldn't cause a crash nor "something unintended". Compatibility problems with .elc files compiled with other Emacs versions can also come from macros, and those tend to be more frequent than the problems introduced by changes to the byte-code. So detecting a different byte-code version is not sufficient to catch the most common problems anyway. FWIW, I think Emacs deserves a new Elisp compilation system (either a new kind of bytecode (maybe using something like vmgen), or a JIT or something): the bytecode we use is basically identical to the one we had 20 years ago, yet the tradeoffs have changed substantially in the mean time. Stefan