From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.devel,gmane.lisp.guile.user Subject: Re: Keywords in GOOPS methods Date: Fri, 22 Nov 2024 13:28:34 +0100 Message-ID: References: <87iksg2qnm.fsf@gnu.org> <8734jj1oey.fsf@wolfsden.cz> Reply-To: mikael@djurfeldt.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000002100ee06277f8643" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1160"; mail-complaints-to="usenet@ciao.gmane.io" To: Mikael Djurfeldt , janneke@gnu.org, guile-devel , =?UTF-8?Q?Ludovic_Court=C3=A8s?= , guile-user , Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Fri Nov 22 13:29:08 2024 Return-path: Envelope-to: guile-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 1tESma-00006b-Cm for guile-devel@m.gmane-mx.org; Fri, 22 Nov 2024 13:29:08 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tESmK-0003vk-PU; Fri, 22 Nov 2024 07:28:52 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tESmJ-0003vI-DY; Fri, 22 Nov 2024 07:28:51 -0500 Original-Received: from mail-ot1-f41.google.com ([209.85.210.41]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tESmG-0003bI-Su; Fri, 22 Nov 2024 07:28:50 -0500 Original-Received: by mail-ot1-f41.google.com with SMTP id 46e09a7af769-7180ab89c58so1027875a34.1; Fri, 22 Nov 2024 04:28:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732278526; x=1732883326; h=to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6hVRduj3/Zou/cVlfTNZjZIDbINJE6fawpzRCguwydA=; b=ANveEuJaORwJ+tdwXcigOJeCF7aj+ASumYT1QLbVYtHG0dYDEZpQaOiHPWUpTGr1SP ctFfLb8riO+ZTDFgF2PIdiHri3dAzg2UZWvB+pYgVpf6ucd0SWLY1s9DoWdmXDN90Zxy B3/wq2RS8unlueiOat9Hm99Cv/vRgIT2HIMkTkpQhj58QHSPINTxJcX5cpfSdyxL63Dm YmC8NsignsO/3hwmAP6gKlLE9uuN5yRPuFcpCH+czhkQS1e2Gm0lxEbFIdYERMNQrTF7 Kkbh2N1VYKvB0vUGs41Mqg+tRENoVuT2mxTgj1UhqbR5kLvg7TnKECtvwXtRxviHx31w 6CJw== X-Forwarded-Encrypted: i=1; AJvYcCU5fENFnHaTH1RuHySfVfwBRJjUEFp2Er3UFgpWOtLYCOarLD3j2Z/9/rxQ18ut+ujObOGrkSgiIwT+IA==@gnu.org, AJvYcCVDQEoFqWyUz/+KGLF3/UkOPmDUXIuEimAuqUta+qP2L0zLewWCqURBrLrgjJFCkCPxcBcIvw==@gnu.org, AJvYcCWXyyqJVlOjLr6tAmnxLk4jL/O7WyraOkW59tcSaSvkegQcTkFQbSy3tDOwZQsf8t/MewRt4XnBAA==@gnu.org, AJvYcCX0y4CQN/miQzC4uv8D0N23t1cnBmsPZxcAfCphl5Q1nLZez2deQBJ815aUGOaM6D5+VPNTzTsnCXdw/g==@gnu.org X-Gm-Message-State: AOJu0YxeQmHzO/SBIxZ5wbyDN6UVORIuwIg8B1UTF4B4GCHGFWP0/TAQ 3Vi0QHexpL8LnJGeVkPxkwihKRKbDjyM2hC3hicnDeAEB4UecJREaouJnQAr/HH/qqLGN5v7nOy ncbHsBcNEtU/xmRbWpwDmkGo1x0IuWw== X-Gm-Gg: ASbGncs5mqDp8GwB8IKPMU0Hu6xA20hBADFYWbxybMBXSJalH9ms+wA7bjl/M/YG5Rw q3He4AJ7sFzG7X400W6dhQpl/YA0eURlh X-Google-Smtp-Source: AGHT+IFEwA3u+WTQgMn5zHCF/f1HYm86Ow1+O8VgMGMPAsn1i4/iiUYaHGtbysif/0F+VxsxEhQJD4cLQF07074XsG8= X-Received: by 2002:a05:6358:7e06:b0:1c6:505:7a9d with SMTP id e5c5f4694b2df-1ca7970d0cfmr225729455d.2.1732278524900; Fri, 22 Nov 2024 04:28:44 -0800 (PST) In-Reply-To: <8734jj1oey.fsf@wolfsden.cz> Received-SPF: pass client-ip=209.85.210.41; envelope-from=mdjurfeldt@gmail.com; helo=mail-ot1-f41.google.com X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.devel:22786 gmane.lisp.guile.user:19913 Archived-At: --0000000000002100ee06277f8643 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tomas, Thank you for your feedback. Answers below. On Fri, Nov 22, 2024 at 12:46=E2=80=AFPM Tomas Volf <~@wolfsden.cz> wrote: > I do find the symmetry between define-method/define-method* and > define/define* pleasing. > Yes, I guess we are free to form GOOPS in our own style regardless of CLOS. > For define and define*, one could argue that procedures produced by the > latter are slower to call (I did measure). Is that an issue here as > well? Well, the implementation in my patch essentially does the same amount of work as the old one, and when not using keywords a call is as efficient. Generic function dispatch should be unaffected, as with Marks macro. However, there will be the same kind of overhead as for define* in calls actually using keywords. I checked what the optimizer can do with the resulting method when using Marks elegant macro. Unfortunately, such a method would have overhead. However, I do think that a modified version of Marks macro together with a small change in peval could have a chance not to introduce such overhead. All, in all, it currently (and paradoxically) turns out to be simpler to provide the keyword functionality in define-method rather than also providing define-method* if one doesn't want to introduce overhead for the most common types of methods. Perhaps I could try to learn what is going on in peval and see if a macro similar to Marks would be the most elegant way to go forward. You did mention backwards compatibility, but how serious you expect the > issue would be? I personally did not use GOOPS yet, but I have a hard > time imagining a real-world code that would be broken by this change. > Do you expect there would actually be any? > I said "backwards compatibility perspective" and was too lazy to spell out what I meant, which is this: Assume that we *now* want to write backwards compatible code. Then, if we have *not* modified define-method we can be certain that as long as we use define-method, we will be backwards compatible. However, if we introduce keywords in define-method (rather than define-method*) this is no longer true. If this new functionality is confined to define-method*, then a future code can test for the presence of defined-method* in Guile and otherwise provide something similar to Marks (or Anders Vinjars from April 2003 :-)) macro. > > I personally would probably lean towards two separate procedures (mainly > due to the assumption of there being a performance impact). > Well, there is none now that we have Andys remarkable compiler. Now also Janneke has responded and he prefers to have everything in define-method. Myself, I'm split. I can see merits in both solutions. Least code bloat would probably be to just apply my patch. But I think we should think mostly about style (where I am still split). Best regards, Mikael > > Have a nice day, > Tomas Volf > > -- > There are only two hard things in Computer Science: > cache invalidation, naming things and off-by-one errors. > --0000000000002100ee06277f8643 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tomas,

Thank you for your= feedback. Answers below.

On Fri, Nov 22, 2024 at 12:46=E2=80=AFPM Toma= s Volf <~@wolfsden.cz> wrote:
<= /div>
I do find the symmet= ry between define-method/define-method* and
define/define* pleasing.

Yes, I guess w= e are free to form GOOPS in our own style regardless of CLOS.
=C2=A0
For define and define*, one could argue that procedures produced by the
latter are slower to call (I did measure).=C2=A0 Is that an issue here as well?

Well, the implementation in my patch = essentially does the same amount of work as the old one, and when not using= keywords a call is as efficient. Generic function dispatch should be unaff= ected, as with Marks macro. However, there will be the same kind of overhea= d as for define* in calls actually using keywords.

I checked what the optimizer can do with the resulting method when using M= arks elegant macro. Unfortunately, such a method would have overhead. Howev= er, I do think that a modified version of Marks macro together with a small= change in peval could have a chance not to introduce such overhead.
<= div>
All, in all, it currently (and paradoxically) turns out = to be simpler to provide the keyword functionality in define-method rather = than also providing define-method* if one doesn't want to introduce ove= rhead for the most common types of methods.

Perhap= s I could try to learn what is going on in peval and see if a macro similar= to Marks would be the most elegant way to go forward.

You did mention backwards compatibility, but how serious you expect the
issue would be?=C2=A0 I personally did not use GOOPS yet, but I have a hard=
time imagining a real-world code that would be broken by this change.
Do you expect there would actually be any?

<= div>I said "backwards compatibility perspective" and was too lazy= to spell out what I meant, which is this: Assume that we *now* want to wri= te backwards compatible code. Then, if we have *not* modified define-method= we can be certain that as long as we use define-method, we will be backwar= ds compatible. However, if we introduce keywords in define-method (rather t= han define-method*) this is no longer true. If this new functionality is co= nfined to define-method*, then a future code can test for the presence of d= efined-method* in Guile and otherwise provide something similar to Marks (o= r Anders Vinjars from April 2003 :-)) macro.
=C2=A0

I personally would probably lean towards two separate procedures (mainly due to the assumption of there being a performance impact).

Well, there is none now that we have Andys remarkable = compiler. Now also Janneke has responded and he prefers to have everything = in define-method. Myself, I'm split. I can see merits in both solutions= . Least code bloat would probably be to just apply my patch. But I think we= should think mostly about style (where I am still split).
Best regards,
Mikael
=C2=A0

Have a nice day,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
--0000000000002100ee06277f8643--