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: Should records be able to mimic primitive types? Date: Fri, 16 Jun 2017 15:07:05 -0400 Message-ID: References: <8777899d-ca8e-212c-b8bf-2f8da4c54836@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1497640037 19999 195.159.176.226 (16 Jun 2017 19:07:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Jun 2017 19:07:17 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Philipp Stephani Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 16 21:07:13 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 1dLwaP-000513-1u for ged-emacs-devel@m.gmane.org; Fri, 16 Jun 2017 21:07:13 +0200 Original-Received: from localhost ([::1]:60419 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dLwaU-0003N4-EU for ged-emacs-devel@m.gmane.org; Fri, 16 Jun 2017 15:07:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47627) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dLwaO-0003My-5e for emacs-devel@gnu.org; Fri, 16 Jun 2017 15:07:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dLwaL-0002sr-0C for emacs-devel@gnu.org; Fri, 16 Jun 2017 15:07:12 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:47446) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dLwaK-0002sA-QT for emacs-devel@gnu.org; Fri, 16 Jun 2017 15:07:08 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id v5GJ76Su010040; Fri, 16 Jun 2017 15:07:06 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id EDBEF606E7; Fri, 16 Jun 2017 15:07:05 -0400 (EDT) In-Reply-To: (Philipp Stephani's message of "Fri, 16 Jun 2017 18:42:08 +0000") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6049=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6049> : inlines <5933> : streams <1750207> : uri <2444935> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:215682 Archived-At: >> Will all 3 steps ever occur at the same time? > I don't think this is an important question. But in the absence of the combination of those 3 steps, your check will make no difference. Are you saying that you don't think "whether my check makes a difference" is an important question? > The important point is: Previously, there were invariants such as > (integerp x) == (eq (type-of x) 'integer) or that prin1 would only > generate #s(hash-table ...) for actual hash tables. Now these > invariants are broken. Every patch we install changes an "invariant" (except for cosmetic patches, changes to the build system, ...). So we can't take such an absolute position, if we want to keep developing Emacs (including fixing bugs): we necessarily have to judge which invariants are worthy of being preserved and which ones aren't. E.g. if we ever get good support for bignums, we'll likely have to break your first invariant. Also we have to distinguish between breaking an invariant and not enforcing it. I do consider an Elisp code which creates a record of type `integer` as a bug, but I don't think it's worth this particular effort to enforce it. Even with your extra check the above two invariants won't always hold. I can trivially break the first one with some add-advice on type-of. Should we add another check to prevent breaking the "invariant" in that other way? The second can be broken without even using an advice on `prin1` simply by creating a record of type (make-symbol "hash-table"). Should we also add yet another check to try and avoid this other way to break your "invariant"? > But there's a discontinuity between "invariant is guaranteed" and > "invariant is almost always guaranteed": the latter is identical to > "invariant is not guaranteed at all". In Elisp, the general rule is that thanks to the dynamic nature of the language, there are precious few invariants which really always hold. E.g. as soon as your "invariant" calls a function by name, you're exposed to breakage via the advice mechanism. So, in a sense, Elisp is a landmine just like C. > Yes, absolutely. I don't care whether it's rare or hypothetical, it breaks > an invariant, and invariants must not be broken. You might like to try Agda or Coq, but Elisp will inevitably disappoint you in this area. In case you're interested, my own hobby language, Typer, tries to combine Coq with Lisp. Stefan