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: Thu, 21 Nov 2024 21:33:43 +0100 Message-ID: References: Reply-To: mikael@djurfeldt.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000069cf6f0627722fa6" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24274"; mail-complaints-to="usenet@ciao.gmane.io" To: 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 Thu Nov 21 21:34:12 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 1tEDsQ-0006CV-Rh for guile-devel@m.gmane-mx.org; Thu, 21 Nov 2024 21:34:10 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tEDsO-0004AD-Jz; Thu, 21 Nov 2024 15:34:08 -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 1tEDsG-00042S-80; Thu, 21 Nov 2024 15:34:00 -0500 Original-Received: from mail-oa1-f45.google.com ([209.85.160.45]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tEDsE-0006cu-0b; Thu, 21 Nov 2024 15:33:59 -0500 Original-Received: by mail-oa1-f45.google.com with SMTP id 586e51a60fabf-2689e7a941fso934677fac.3; Thu, 21 Nov 2024 12:33:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732221235; x=1732826035; 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=fKDN0Ka5hhKPrtpCzcGtOqoXL0OXGckgIRHaGiyOtB4=; b=VkVy5gVMnXZYJ+Q5mbVGe1lizdXKjdgelcew84j/z8xysbs5NIqOL/5UqnorXvTV2a nhX7taAtzUUD411jPH3jYdOqM3Kd4DhS0k3GME4IhYnjjUg9jt97UGEF8UDrLqKYAe6r FF/KHFv9i/TCsxz3LkQmpzNnk+5MBRVrFecQIHYn1mmDbXfT2gEoV5vacAAKEHdSvxyU 5DwpJY6ePxHeXmM2ko5lfkgimdqdMLSzoz2imheZslIximN18yYAlHNo+xWsllgVKUQ+ ptf1VmLnB2Yh+YA3MM3px6gd9m9wg928skqoYvAYHJNu/TBircEfhzalhrmgQ6T+Wboq Umnw== X-Forwarded-Encrypted: i=1; AJvYcCUJApVdKBdFlbXidJXNKNeLfr+9wrjN8f35AKwhcU5ed7f46D1GR9xTBoC2pHj9obj7WJbyzA==@gnu.org, AJvYcCVVK2Kdg5zgymC8kYTsPQ7PBj6skZHaKX9aEBJSAnAwh9MQo0ZI0JPCU3q+ML2lW9f3j9K6lFMnNVn8@gnu.org X-Gm-Message-State: AOJu0YwIzKqRR0ztQqICULRHPADETVJGfeeCWj6kzoHkSMmclbyKGfjK DC1zVbCHpeC0VHiV5d6Riuc23/5D1djge4TjQ6+V7JdyLbWDt6Na/xwTQqTspUFefBS98NEA1ut a0EOtQ2EBv+yaKHtiBh7KXHc6zkW2GA== X-Gm-Gg: ASbGncumnscGi/29okUKo0tQVjYQqfayaVYf90KAObMzRXFeiINU2NaLNhTXDFs3z7i 3nMakvS0avLHbYjTarb8uIz5wKu7UdVWf X-Google-Smtp-Source: AGHT+IEqcSQohO2ZrjHt4oMzUrPxXWdEcKJgMbsnDoPD8pX/NpglTV9lmYZgXWbW/QUSWXZXJ+X+kfmN75JlXHm0HoI= X-Received: by 2002:a05:6358:60ce:b0:1c3:889b:880f with SMTP id e5c5f4694b2df-1ca797bdd6cmr68417155d.20.1732221235480; Thu, 21 Nov 2024 12:33:55 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=209.85.160.45; envelope-from=mdjurfeldt@gmail.com; helo=mail-oa1-f45.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:22781 gmane.lisp.guile.user:19908 Archived-At: --00000000000069cf6f0627722fa6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (I will of course add proper documentation in the manual, etc.) On Thu, Nov 21, 2024 at 9:33=E2=80=AFPM Mikael Djurfeldt wrote: > Since there are no comments, I'm inclined to apply this patch. I will do > that on Sunday if there are no comments before that. > > Maybe I should first give a motivating example: guile-mqtt consists of a > thin wrapper over NYACC-generated code. There, I use a coding pattern tha= t > I tend to use in cases where methods need keyword arguments: > > (define-method (subscribe (client ) (topic ) . > args) > (define* (subscribe #:key (qos 0)) > (mosquitto_subscribe (mosq client) %null-pointer topic qos)) > (apply subscribe args)) > > With the change I propose, this can be written: > > (define-method (subscribe (client ) (topic ) > #:key (qos 0)) > (mosquitto_subscribe (mosq client) %null-pointer topic qos))) > > with the same resulting semantics. > > There is one question that I'd like people to think about, though: In my > patch I have adhered to the close relationship with CLOS, where defmethod > takes keyword, optional and rest arguments similar to Guile's define*, an= d > extended the method syntax itself. As an alternative, we could let the > current method syntax stay as is and implement new define-method* and > method* syntax. In some ways this would be cleaner, for example from a > backward compatibility perspective. On the other hand it might feel like > overkill to have so much syntax. Implementation and performance wise it > shouldn't matter much how we choose to do, except that adding > define-method* and method* of course adds more code to the implementation= ... > > Best regards, > Mikael > > On Tue, Nov 19, 2024 at 5:41=E2=80=AFPM Mikael Djurfeldt > wrote: > >> Hi all, >> >> I've implemented support for keyword arguments (corresponding to define* >> and lambda*) in GOOPS. The functionality is similar to that of CLOS (whi= ch >> also has keyword in methods) in that dispatch is not done on the keyword >> part. >> >> You can find the changes in the goops-keyword branch at >> https://github.com/mdjurfeldt/guile/tree/goops-keyword or in the >> included patch. >> >> Comments? >> >> Best regards, >> MIkael >> >> --00000000000069cf6f0627722fa6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(I will of course add proper documentation in the manual, = etc.)

On Thu, Nov 21, 2024 at 9:33=E2=80=AFPM Mikael Djurfeldt <mikael@djurfeldt.com> wrote:
<= /div>
Since there are no comments, I'm inclined to apply this patch. I will= do that on Sunday if there are no comments before that.

Maybe I should first give a motivating example: guile-mqtt consists = of a thin wrapper over NYACC-generated code. There, I use a coding pattern = that I tend to use in cases where methods need keyword arguments:
=

(define-method (subscribe (client <mosquitto-client&= gt;) (topic <string>) . args)
=C2=A0 (define* (subscribe #:key (qo= s 0))
=C2=A0 =C2=A0 (mosquitto_subscribe (mosq client) %null-pointer top= ic qos))
=C2=A0 (apply subscribe args))

With th= e change I propose, this can be written:

(define-m= ethod (subscribe (client <mosquitto-client>) (topic <string>) #= :key (qos 0))
=C2=A0 (mosquitto_subscribe (mosq client) %null-pointer to= pic qos)))

with the same resulting semantics.

There is one question that I'd like people to thin= k about, though: In my patch I have adhered to the close relationship with = CLOS, where defmethod takes keyword, optional and rest arguments similar to= Guile's define*, and extended the method syntax itself. As an alternat= ive, we could let the current method syntax stay as is and implement new de= fine-method* and method* syntax. In some ways this would be cleaner, for ex= ample from a backward compatibility perspective. On the other hand it might= feel like overkill to have so much syntax. Implementation and performance = wise it shouldn't matter much how we choose to do, except that adding d= efine-method* and method* of course adds more code to the implementation...=

Best regards,
Mikael
On Tue, N= ov 19, 2024 at 5:41=E2=80=AFPM Mikael Djurfeldt <mikael@djurfeldt.com> wrote:
<= /div>
Hi all,

I've implemented support for key= word arguments (corresponding to=20 define* and lambda*) in GOOPS. The functionality is similar to that of=20 CLOS (which also has keyword in methods) in that dispatch is not done on th= e keyword part.

You can find the changes in the go= ops-keyword branch at https://github.com/mdjurfeldt/guile/tree/go= ops-keyword or in the included patch.

Comments= ?

Best regards,
MIkael

--00000000000069cf6f0627722fa6--