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: Sat, 23 Nov 2024 00:04:30 +0100 Message-ID: References: <87iksg2qnm.fsf@gnu.org> <87h67zxxxn.fsf@gnu.org> Reply-To: mikael@djurfeldt.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000736bdc06278868d1" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24518"; mail-complaints-to="usenet@ciao.gmane.io" Cc: guile-devel , =?UTF-8?Q?Ludovic_Court=C3=A8s?= , guile-user , Andy Wingo To: janneke@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Sat Nov 23 00:05:04 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 1tEchz-0006Ba-9s for guile-devel@m.gmane-mx.org; Sat, 23 Nov 2024 00:05:03 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tEchn-0006bD-Du; Fri, 22 Nov 2024 18:04:51 -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 1tEchl-0006as-UB; Fri, 22 Nov 2024 18:04:49 -0500 Original-Received: from mail-qk1-f173.google.com ([209.85.222.173]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tEchj-0004xh-7J; Fri, 22 Nov 2024 18:04:49 -0500 Original-Received: by mail-qk1-f173.google.com with SMTP id af79cd13be357-7b155da5b0cso169979585a.2; Fri, 22 Nov 2024 15:04:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732316682; x=1732921482; h=cc: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=/dJIRFA52KP/tuHzwO9OVBFpijKhT+XlmMKK9egMoTQ=; b=h9vLKize06AySjITqWXXZwMOuLoQ7uuM/QKu/kE5qwqsNrHa0A0B4pkJwF6N4PfI0M GH9WRMadKHSJbJcsH8KivebM/WfS0NVsJHQuvZYMWduClnjuNyPPto5GLfB9oH2nx2Oa o+N3buMrzXnHGgxexKEnLwZ3UpWNqqVF1WAFBiYtRU6ckSbQn+ONr2qZKPr07HWDgvs0 iqE8Dw8vHXlI/YbbV6NBzSzdWDlZiLSV//VcLqsPISFDH5dhcZZ/eN9cg2C1XVfxVakq W2EMfyJJTTIFR3jhS2TtdzIfyoSvHBYgHQOzES3DFrfeqoFfOCG5AFaIX+DhqpJIVzjc HmTQ== X-Forwarded-Encrypted: i=1; AJvYcCV0d8cNxWxgR8XgKsddVEGEpbHCXATyzvxZAlxhz/ftFv780ToejX8k+yiB3ivPWXelTZ+D4A==@gnu.org, AJvYcCWJqd4X8FbStWL/3kU7Sgqn2/0d1X3mkMLPq/+069lYz4Dp+iHevS11+yAnQHRYvCZXSMtGriuCIddZ@gnu.org X-Gm-Message-State: AOJu0YxhJAhUqQftJ/EfyQeP15Y7/V+JKHspFQLMfRKzSua3DQ1uVHHD 8iCjfazzksMQIk4TCX52SD5gG9W+Tvuwxiv4VyzH9vysYIEHqg9+eIUknjHzuqw8a86MtxlNcER zONmRDXZEUv2pslP2hy2aBWVx++1APn8p X-Gm-Gg: ASbGnct+V1cnyqTk3cgpkHfNucS/jzP6H4hExORzVJAKBj8f/0JbLFlQEwHWNrx3LNp c7cDWYm/925nEJiSScjLDvlq+FkJtGUes X-Google-Smtp-Source: AGHT+IEO0eVgv9CNqUWCDzas32noudMAslyTB3UGtV2lgk1c8cna/HSZh3SCohPNWSDP/D+PnQyiAVx41yidEF1EVvQ= X-Received: by 2002:a05:620a:1a92:b0:7b1:4948:109f with SMTP id af79cd13be357-7b514646592mr495032185a.57.1732316681691; Fri, 22 Nov 2024 15:04:41 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=209.85.222.173; envelope-from=mdjurfeldt@gmail.com; helo=mail-qk1-f173.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_H2=-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:22788 gmane.lisp.guile.user:19915 Archived-At: --000000000000736bdc06278868d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ChatGPT is also split...: Given the circumstances, I would recommend extending define-method rather than introducing define-method*. Here=E2=80=99s why: 1. *Consistency and Simplicity*: By extending define-method, you avoid creating a dual system where users have to choose between define-method and define-method*. This reduces cognitive overhead and makes the API cleaner. 2. *Backwards Compatibility*: As long as the extension maintains backwards compatibility=E2=80=94e.g., methods defined without optional, keyword, o= r rest arguments continue to work as before=E2=80=94there=E2=80=99s minimal ris= k of breaking existing code. 3. *Ease of Use*: Users generally prefer fewer forms to remember. Adding more features to the existing define-method aligns with the principle of least surprise for anyone using GOOPS. 4. *Future-Proofing*: Creating a parallel form like define-method* could set a precedent for duplicating functionality every time a significant feature is added, leading to API bloat over time. The counterargument might be that adding optional, keyword, and rest arguments complicates define-method=E2=80=99s semantics. However, if these = features integrate naturally and don=E2=80=99t break current assumptions, the benefi= ts of a unified approach outweigh the risks. My confidence in this recommendation is 85%, as the best decision ultimately depends on the specifics of your user base and how GOOPS is typically used. If there's significant risk of confusion or breaking changes in the extension, introducing define-method* might then become a better option. 4o You said: But Guile already has define* and lambda* forms... ChatGPT said: The existence of define* and lambda* in Guile suggests a precedent for introducing parallel forms to extend functionality. This could justify introducing define-method* for consistency with Guile's conventions. Here's a revised analysis based on this: 1. *Consistency with Guile*: Introducing define-method* aligns GOOPS with Guile's existing patterns, making it feel more integrated into the Guile ecosystem. Users familiar with Guile would likely expect an extended for= m with a * suffix for enhanced functionality. 2. *Avoiding Overloading Semantics*: Extending define-method could make its behavior more complex and potentially harder to understand for users who only need the basic functionality. Having a separate define-method* clearly distinguishes the advanced features, keeping both forms conceptually simpler. 3. *Backward Compatibility and Clarity*: A new form eliminates any chance of subtle incompatibilities or ambiguities arising from extending define-method. For example, users writing macros or tooling around define-method won't need to account for new syntax or semantics. 4. *Gradual Adoption*: With define-method*, users can adopt the new functionality incrementally. This reduces friction for existing users wh= o may not need or want the added complexity of optional, keyword, and rest arguments. Given Guile's * convention, introducing define-method* appears to be the better option. It respects established practices, avoids over-complicating existing forms, and provides a clear upgrade path. My confidence in this recommendation is 90%, given that the Guile precedent is a strong argument for following suit. 4o On Fri, Nov 22, 2024 at 1:29=E2=80=AFPM Mikael Djurfeldt wrote: > Thanks! > > See responses to Tomas. > > On Fri, Nov 22, 2024 at 1:20=E2=80=AFPM wrote: > >> Mikael Djurfeldt writes: >> >> Hello, >> >> > That was elegant. :-) >> >> :) >> >> > Nope---haven't seen it. (Or, at least I do not remember it.) >> > >> > Maybe I should have a look at what the optimizer can do about Mark's >> > code. (As you might have seen, my code is a modification of the method >> > syntax implementation itself.) >> >> Yes, I didn't quite get if this brings something else too, except for >> the obvious >> >> > Any opinions on what is best: Having a define-method* or having the >> > functionality in define-method itself? >> >> ...which I think in your version, not having to use define-method* >> feels more elegant/GOOPSy to me, as it's all overloads/generics, >> but I have no strong opionion on this. Thanks for working on this! >> >> Greetings, >> Janneke >> >> -- >> Janneke Nieuwenhuizen | GNU LilyPond >> https://LilyPond.org >> Freelance IT https://www.JoyOfSource.com | Avatar=C2=AE >> https://AvatarAcademy.com >> > --000000000000736bdc06278868d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

ChatGPT is also split...:

Given= the circumstances, I would recommend extending define-method = rather than introducing define-method*.

Here=E2=80=99s w= hy:

  1. Consistency and Simplicity: By extending= define-method, you avoid creating a dual system where users h= ave to choose between define-method and define-method*. This reduces cognitive overhead and makes the API cleaner.

    2. <= li>

    Backwards Compatibility: As long as the extension ma= intains backwards compatibility=E2=80=94e.g., methods defined without optio= nal, keyword, or rest arguments continue to work as before=E2=80=94there=E2= =80=99s minimal risk of breaking existing code.

  2. Ease= of Use: Users generally prefer fewer forms to remember. Adding mo= re features to the existing define-method aligns with the prin= ciple of least surprise for anyone using GOOPS.

  3. Futu= re-Proofing: Creating a parallel form like define-method* could set a precedent for duplicating functionality every time a signi= ficant feature is added, leading to API bloat over time.

Th= e counterargument might be that adding optional, keyword, and rest argument= s complicates define-method=E2=80=99s semantics. However, if t= hese features integrate naturally and don=E2=80=99t break current assumptio= ns, the benefits of a unified approach outweigh the risks.

My confide= nce in this recommendation is 85%, as the best decision ultimately depends = on the specifics of your user base and how GOOPS is typically used. If ther= e's significant risk of confusion or breaking changes in the extension,= introducing define-method* might then become a better option.=

=
You said:<= /h5>
But = Guile already has define* and lambda* forms...
<= /div>
ChatGPT said:

The existence of = define* and lambda* in Guile suggests a precedent= for introducing parallel forms to extend functionality. This could justify= introducing define-method* for consistency with Guile's c= onventions. Here's a revised analysis based on this:

  1. Consistency with Guile: Introducing define-method* aligns GOOPS with Guile's existing patterns, making it feel more inte= grated into the Guile ecosystem. Users familiar with Guile would likely exp= ect an extended form with a * suffix for enhanced functionalit= y.

  2. Avoiding Overloading Semantics: Extendin= g define-method could make its behavior more complex and poten= tially harder to understand for users who only need the basic functionality= . Having a separate define-method* clearly distinguishes the a= dvanced features, keeping both forms conceptually simpler.

  3. <= strong>Backward Compatibility and Clarity: A new form eliminates a= ny chance of subtle incompatibilities or ambiguities arising from extending= define-method. For example, users writing macros or tooling a= round define-method won't need to account for new syntax o= r semantics.

  4. Gradual Adoption: With d= efine-method*, users can adopt the new functionality incrementally. = This reduces friction for existing users who may not need or want the added= complexity of optional, keyword, and rest arguments.

Given= Guile's * convention, introducing define-method* appears to be the better option. It respects established practices, av= oids over-complicating existing forms, and provides a clear upgrade path. M= y confidence in this recommendation is 90%, given that the Guile precedent = is a strong argument for following suit.

<= /div>

On Fri, Nov 22, 2024 at 1:29=E2=80=AFPM Mikael Djurfeldt <mikael@djurfeldt.com> wrote:
= Thanks!

See responses to Tomas.
On Fri, N= ov 22, 2024 at 1:20=E2=80=AFPM <janneke@gnu.org> wrote:
Mikael Djurfeldt writes:

Hello,

> That was elegant. :-)

:)

> Nope---haven't seen it. (Or, at least I do not remember it.)
>
> Maybe I should have a look at what the optimizer can do about Mark'= ;s
> code. (As you might have seen, my code is a modification of the method=
> syntax implementation itself.)

Yes, I didn't quite get if this brings something else too, except for the obvious

> Any opinions on what is best: Having a define-method* or having the > functionality in define-method itself?

...which I think in your version, not having to use define-method*
feels more elegant/GOOPSy to me, as it's all overloads/generics,
but I have no strong opionion on this.=C2=A0 Thanks for working on this!
Greetings,
Janneke

--
Janneke Nieuwenhuizen <janneke@gnu.org>=C2=A0 | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar=C2=AE https://Avata= rAcademy.com
--000000000000736bdc06278868d1--