From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Improve detection of local function calls in methods Date: Fri, 10 Sep 2021 11:49:59 -0400 Message-ID: References: <878s0mva4u.fsf@gmail.com> <87zgt0sdbg.fsf@gmail.com> <87ee9xq74a.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23079"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: akater Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 10 17:51:22 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 1mOioE-0005kU-Al for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Sep 2021 17:51:22 +0200 Original-Received: from localhost ([::1]:57444 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mOioC-0003S0-JH for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Sep 2021 11:51:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57980) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mOin1-0002gY-TM for emacs-devel@gnu.org; Fri, 10 Sep 2021 11:50:07 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:56834) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mOimy-0004E6-RH for emacs-devel@gnu.org; Fri, 10 Sep 2021 11:50:06 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 72DA1440735; Fri, 10 Sep 2021 11:50:02 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 0D39A4409B0; Fri, 10 Sep 2021 11:50:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1631289001; bh=wXExpsMQ33lSdiqrHSBvK34bG5FW36985Ko2/4CBiXE=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=VMN1qtnAT0I/lpLTczLgov3GUCZ76AGb5b6W1myw8xP6fPEtEJtJDTu4Ukknba1pQ e3nxQdEN+KGymtnphZJE3f/ax9T6x8/U4bb2CHtlQ9VDzmkGoynG9VnGsxPvlfZ/9R OGtObL5NkOYrE0LxvDptyBK77i8KVyZi/uV6Z/b8OMZ6MaOpEDVsxxcUQSgGmU5SSQ Sp7tneVsb4RPmVxzkIkjElvZJspIBhJMASbO/x+E4ZX/5yKFzHA4VhHEixwOgE0nuV 5i9ziz5WM+5spH9QnEMVwVeDjErODfZRkSPbHCmS+rEGTj4v6k6nohEgPKt3M9dg9X PAnWCQOxJUYMw== Original-Received: from ceviche (modemcable004.216-203-24.mc.videotron.ca [24.203.216.4]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C1316120249; Fri, 10 Sep 2021 11:50:00 -0400 (EDT) In-Reply-To: <87ee9xq74a.fsf@gmail.com> (akater's message of "Fri, 10 Sep 2021 06:25:57 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:274520 Archived-At: > - (func exp) is non-standard and ad-hoc. (FUNC EXP) is indeed non-standard. But I completely disagree with `ad-hoc`: IMO this form is the fundamental form of `flet` (it corresponds directly to `let`, just in the function namespace) and the form (FUNC ARGS &rest BODY) should be viewed as a simple syntactic sugar for the common case of (FUNC (lambda ARGS &rest BODY)). > Do you happen to remember, maybe it was invented solely for > ~cl--generic-lambda~? It was added to Emacs's `master` for the purpose of `cl--generic-lambda`, yes. It was invented long before, OTOH ;-) [ I still can't explain how I forgot to add it when we moved from `flet` to `cl-flet` in Emacs-24.3. ] > - (func exp) definition form is described incorrectly in the docstring: > it should be (FUNCTION-NAME SYMBOL) and so on; Not sure what you mean here. Do you mean `func` should be `function-name` since this should be a symbol and not a function? [ I would agree with that, tho `function-name` would be longish so I'd rather go maybe with just `name`. ] Or do you mean that `exp` should be `symbol`? If so, I disagree because this allows an arbitrary expression that's evaluated before its resulting value is bound to the specified function symbol. > this also affects `cl-macrolet` docstring which claims it's =E2=80=9Cli= ke > `cl-flet`=E2=80=9D but in fact it's not as it doesn't support this defi= nition > form Indeed, this was not updated when `cl-flet` was extended. Not sure what's best to do here: - we could extend `cl-macrolet` to also accept (NAME EXP), but this is much less useful for macros since EXP is evaluated in the macroexpansion context. - tweak the docstring to clarify the "like"ness. > - ~cl-flet~ with invalid function names should error but it doesn't You mean if the "function name" is not a symbol? Indeed, it would be better to signal an error in that case. > This involves a =E2=80=9Cmacro=E2=80=9D version of expand-flet; we'll see= whether it's > worth keeping alongside the corresponding function. Your sample code looks OK, tho I don't think having a macro for it is worth the trouble. Stefan