From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium Date: Tue, 28 Apr 2020 15:51:11 -0700 (PDT) Message-ID: <1b05adb5-9629-4462-b63d-5ce614070b52@default> References: <69d8b48d-bd09-41c1-a89d-ed76fe0284a4@default> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="84027"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Andrea Corallo , Stefan Kangas , Emacs developers To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 29 00:53:51 2020 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 1jTZ6s-000Ljb-NC for ged-emacs-devel@m.gmane-mx.org; Wed, 29 Apr 2020 00:53:50 +0200 Original-Received: from localhost ([::1]:60774 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jTZ6r-0002rN-QK for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Apr 2020 18:53:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57488) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jTZ6M-0002QO-8k for emacs-devel@gnu.org; Tue, 28 Apr 2020 18:53:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jTZ6L-0001a0-FH for emacs-devel@gnu.org; Tue, 28 Apr 2020 18:53:17 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:42676) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jTZ6K-0001Zt-Tj for emacs-devel@gnu.org; Tue, 28 Apr 2020 18:53:17 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03SMnTbx143690; Tue, 28 Apr 2020 22:53:15 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=zENeuvmxprkKi7SIEMIdVN5TN05BSfmkx90zUaGAUWA=; b=AJSC/WUxZlXiYX/qvuTwQU6FK2ukNThhtWD9FlvOd3XsMRFC/6ZVCWWf7We2zbIvecE/ MXw9LvAUXdtE1U/D5m7LDgAkoUEKwcRwkdQJ2D6pkW9EeX8CuOP9BxHw8mwRzn5kmaMH jg1U3eoE7OndXF7FFMOdQvkljX5w+aRwL3lCGEHjU0yfgzp/tFvCPxT7n+EERcc1flq6 b+d6sZHrpkPHwroOoTcNUUPVanHez45C6S8nsxckQFz50wFYdshY6t4al2l9cefz/chu YCdJuUaDeTDWEthfFQLHhq9uq9nqVrzqyTKgXZ0jTc+tJ4inlqmCrJW6C6MWw1vdcJvN xA== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 30p01ns9yx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 28 Apr 2020 22:53:14 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03SMkgL9012517; Tue, 28 Apr 2020 22:51:14 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3030.oracle.com with ESMTP id 30mxph7bxa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 28 Apr 2020 22:51:14 +0000 Original-Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03SMpCfU003318; Tue, 28 Apr 2020 22:51:12 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9605 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 malwarescore=0 mlxscore=0 bulkscore=0 adultscore=0 phishscore=0 suspectscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004280176 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9605 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 spamscore=0 clxscore=1011 phishscore=0 mlxlogscore=999 adultscore=0 priorityscore=1501 mlxscore=0 suspectscore=0 malwarescore=0 lowpriorityscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004280176 Received-SPF: pass client-ip=156.151.31.86; envelope-from=drew.adams@oracle.com; helo=userp2130.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/04/28 18:53:15 X-ACL-Warn: Detected OS = Linux 3.x [generic] [fuzzy] X-Received-From: 156.151.31.86 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:248053 Archived-At: > > Dunno who, besides perhaps Stefan, considers > > dynamic binding in Elisp to be "obsolete and > > close to deprecation". That would be a mistake. >=20 > You're confusing "dynamic binding" with "the > dynamically scoped dialect of Elisp". Dynamic > binding is very much alive in "the lexically scoped > dialect of Elisp" with no plan to deprecate it. You can say I'm confused, and you throw out undefined terms like "the ___ scoped dialect of Elisp". (Undefined in both your mail and the paper. As one of the two main reviewers of the paper, perhaps that's your undefined term?) I'm talking about what Common Lisp calls "indefinite scope and dynamic extent", i.e., what Common Lisp special variables have. https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node43.html What does your "dynamically scoped dialect of Elisp" entail, that's not included in the use of special variables (infinite scope and dynamic extent)? What's excluded in the limitation to "the new lexically scoped dialect only"? If all that you really mean is the behavior when variable `lexical-binding' is nil, then that really should have been made clear. Emacs and Elisp (e.g. the doc) make no mention of that variable defining two different Lisp dialects. If that's all that's meant, it's OK by me. But such terminology is misleading (IMO), without the explanation.