From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] * src/eval.c: Stop checking for nvars, and use only CONSP Date: Tue, 2 Mar 2021 19:50:23 +0000 Message-ID: References: <20210302.111043.609653289571449353.conao3@gmail.com> <20210302.120929.1656994339284323372.conao3@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31184"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Naoya Yamashita , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 02 20:51:35 2021 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 1lHB3P-00080s-Pt for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Mar 2021 20:51:35 +0100 Original-Received: from localhost ([::1]:39660 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHB3O-0006Ka-Na for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Mar 2021 14:51:34 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33252) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHB2s-0005tM-Hf for emacs-devel@gnu.org; Tue, 02 Mar 2021 14:51:02 -0500 Original-Received: from mail-oo1-xc29.google.com ([2607:f8b0:4864:20::c29]:40797) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lHB2q-000828-OG for emacs-devel@gnu.org; Tue, 02 Mar 2021 14:51:02 -0500 Original-Received: by mail-oo1-xc29.google.com with SMTP id l5so5100181ooj.7 for ; Tue, 02 Mar 2021 11:51:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/+yQ5X2W4Zxdk32CDG5srwunJ1h6LFqSgYELSG1IkGQ=; b=UujGhL/cDJEEOTrkHhoj+LRTOHWbUxnE9mqit28SQ6IY2rCIgFdCogMLOPkk/yJJpv GT5+bIM/mOmyURKsIA4NkUKdHvDt80Wagb2GXp5Bh3LQiC/utgKFKfwC7scMSxwnZLOt 3IjVfZkLlq1ABpJSfF4EWUEwZV7/cjzjZvESF54ohizORelnkAnnU7IGTmsvr5y9wIqH sQyCvI7QdE9DE/6O49RDxn1YfbpaK7dm1PNVFjx8XIEnjYxhCe39eu/TLSzHFv9C0R9N gOwRhshgd4S94dlARi3j+Jko8toa/Y+m6KH4+yjna81YSm3js8b1pMokgEfcXlcwTuaX f6tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/+yQ5X2W4Zxdk32CDG5srwunJ1h6LFqSgYELSG1IkGQ=; b=aEv63xw73D35nI2aSeGcw8pXtfuwYZZ3Mxviw0xwTeiNGEJlKlkLfIKcT0jqyXP/rp NsDGb6oCNSKgJEmWcxsd6ATmrXF3sp/bVrxNBeMMfej6fkloJCSu1zZs1Vv5rZj8C+nw 3OACConjWbg3u0Q1cGWf4XBY2R1UkIp3c7u/jqTYTYnlpHuQFexTenbMw4GrY94n/7Kx FKYq+MxZHTs0i2sRJDA4OZN1Cj8YtPrwwFC3mUTGpcBJVZhCX9HsylsE95LDlj8UOZNd ctE9eckwYyLfXX6IbBF+QKbymYsmj/XkjEsc6RTo60vSCc8Jo4jDBKxP/GcpFdEiSljl LhzA== X-Gm-Message-State: AOAM5334e/5yobHwMa+ADb54NYln6s3Oxe98CVXmsdpx+lLIN4HkZRUC x/1tpw44DDAJs+dfdbCZEBOue6ySeKKXXeESRyk= X-Google-Smtp-Source: ABdhPJzdSAbCxKYWf98bQRv1cC9Qu4Vyrhws+s2RJHarkLqWXawNUZobgFF3+CGUPbbkw4sQneqMsXRjoMaejQwKLSM= X-Received: by 2002:a4a:2511:: with SMTP id g17mr18350907ooa.22.1614714659543; Tue, 02 Mar 2021 11:50:59 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::c29; envelope-from=pipcet@gmail.com; helo=mail-oo1-xc29.google.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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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.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:265844 Archived-At: On Tue, Mar 2, 2021 at 5:44 PM Stefan Monnier wrote: > >> > I'm all for a revolution, but it might be a bit early to chop off this > >> > particular king's head... > >> Until we have good debugging support for byte-compiled code, the > >> interpreter isn't going anywhere, indeed. > > We could rewrite it in ELisp, though :-) > > That would mean just replacing the `Flet` in C with another in ELisp, so > it would largely just move the question (which is about diagnosing > invalid code). Two advantages: A macro can be redefined and have its redefinition apply to compiled code; and, if let were implemented as a macro, other letlikes would have a starting point. For example, I'd love (traced-let ((a 1) (b 2) (c (throw 'out nil)) (d 3)) ...) to work (and print "a = 1 b = 2 c = "), but every time I need it it seems more effort to write than just to debug things the old-fashioned way (did I mention it's my non-integral birthday?)... I think this applies to debugging invalid code, too. > > (I dislike the "let" family, mostly for the fact that it is a family. > > It leads naturally to cl-loop.) > > Removing its special-form status wouldn't remove it from the > language, tho :-( It would make it live at the same level as cl-loop or pcase. > [ Personally, I do find `let` important. > Partly because of my let-polymorphism upbringing ;-) ] I do wonder why other languages have moved to the equivalent of (defun f (a) (letq x 1) (+ x a)) or (defun f (a) (+ (letq x 1) a x)) or even (defun f (a) (if (> a 3) (letq x 1) (letq x 2)) (+ x a x)) while Lisps insist you have to be up front and list all your variables when it creates the stack frame. And (letq a 1) (message "a is %S" a) (letq b 2) is easier to read than (let* ((a 1) (_ (message "a is %S" a)) (b 2)) What seems particularly problematic to me is that other languages can emulate "let" easily, but implementing "letq" in ELisp is...an interesting exercise (i.e. I tried and failed). So those are the emacs-devel-relevant questions: Can you implement letq in ELisp? And why does it feel so wrong in ELisp when it's how most other languages do this? For bonus points, make (defun f () (letq g (lambda () (letq-in g g-counter 0) (letq-in f f-counter 0) (incf g-counter) (incf f-counter))) (cons g (lambda () f-counter)) work. Pip