From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Newsgroups: gmane.lisp.guile.devel
Subject: Re: [PATCH v4 4/4] load: Display modules depth in output when using
 %load-verbosely.
Date: Tue, 03 Oct 2023 21:42:22 -0400
Message-ID: <87v8bn5fk1.fsf@gmail.com>
References: <20230925142945.14153-1-maxim.cournoyer@gmail.com>
 <20230925142945.14153-5-maxim.cournoyer@gmail.com>
 <6f5ace52-5ade-cfe2-bbf6-22562db70206@telenet.be>
 <87jzs53suy.fsf@gmail.com>
 <f8f71dc7-3270-5282-32b7-91a28800b43a@telenet.be>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214";
	logging-data="39481"; mail-complaints-to="usenet@ciao.gmane.io"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Cc: guile-devel@gnu.org
To: Maxime Devos <maximedevos@telenet.be>
Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Wed Oct 04 03:42:48 2023
Return-path: <guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org>
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 <guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org>)
	id 1qnquW-000A4T-DR
	for guile-devel@m.gmane-mx.org; Wed, 04 Oct 2023 03:42:48 +0200
Original-Received: from localhost ([::1] helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <guile-devel-bounces@gnu.org>)
	id 1qnquE-0000aM-PS; Tue, 03 Oct 2023 21:42:30 -0400
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 <maxim.cournoyer@gmail.com>)
 id 1qnquD-0000Zx-82
 for guile-devel@gnu.org; Tue, 03 Oct 2023 21:42:29 -0400
Original-Received: from mail-ua1-x936.google.com ([2607:f8b0:4864:20::936])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <maxim.cournoyer@gmail.com>)
 id 1qnquA-0001kG-P6
 for guile-devel@gnu.org; Tue, 03 Oct 2023 21:42:29 -0400
Original-Received: by mail-ua1-x936.google.com with SMTP id
 a1e0cc1a2514c-7ab8265b797so774761241.2
 for <guile-devel@gnu.org>; Tue, 03 Oct 2023 18:42:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1696383745; x=1696988545; darn=gnu.org;
 h=mime-version:user-agent:message-id:in-reply-to:date:references
 :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
 bh=l7D+hhg+Q0mSGtUAhrMVLV8raRu+pAN8kHczqc6oQGc=;
 b=jFfUYw9mB6UmCwoF93c0vcLDGhNKOe0HRv38mwVVTPJOe1nkvWgz6TQQgo6KjgCDO4
 Fh4qsGXo+2Dm6Hl6CG0aGTiZDLk2LApctS+/PCmApPvfjMUK6f/cCugyu6Qk76UIlZRU
 5WDet3wqIXQuEALXBcKDEmvbescVk3jeW9cOpZpkg6Ya82imdmBqnhm0HpVwvk6y7ZVo
 QSLNatveACfhxvozFul60P7sdNjvvS+dZG2EPzYlAjV2XdvZ3HlHVcj2r19xh7YQeAvQ
 blPulf8Dbp4qKcv0c1kk/8knXJpg3HWRPAGDmZtd9nKi6TRHx1szh6JHZF8+Raf/O5kH
 56JA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1696383745; x=1696988545;
 h=mime-version:user-agent:message-id:in-reply-to:date:references
 :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
 :message-id:reply-to;
 bh=l7D+hhg+Q0mSGtUAhrMVLV8raRu+pAN8kHczqc6oQGc=;
 b=CWl1yX157rpdPIQsJgNY0beEb1tC30iObv86/ehAets9irke+RCDh8Pcp20TDhY42H
 81dYxP6k7PJ3sLBSCav+OE008LHOWfhqk6eS1vbyExYRHXD9roGjvnAVL2NJ3v8OxKGB
 Tc1GQoz4Qwmx0E5N7WDFNFc5LlrHmQcbbpSD03LwfuwldmlWzTmA4tM0KCwmJhOzY9hU
 F2BXGlVT/fvrv8rv8Lwf2OQO4p78rwGe59OJsP1EPJOXbrY8go+YPsJWrfO3GOq3tGco
 9iiSfjtDawrc/DRQ2Zs1lC2AlrDpEVtPx5GML7fp0K68qimrS42L9WNkyUCPvOmtk7Zt
 1ZDQ==
X-Gm-Message-State: AOJu0YzLSsck/DhVTbU1siYKF8rM4D23fbFXkE3wYwy73A0BDBvVyv5L
 WcuuRt05b4IR9+mkFi8aQ3QQXUMqG40=
X-Google-Smtp-Source: AGHT+IEyl1Tp4N1sO8Nv6hLwwoOW64HfsWzVlr3ZOyfu4SW8GO9kKeWiAOevIP8E54EnIoQpQkHelg==
X-Received: by 2002:a67:f7d8:0:b0:452:5798:64b6 with SMTP id
 a24-20020a67f7d8000000b00452579864b6mr1108404vsp.29.1696383745008; 
 Tue, 03 Oct 2023 18:42:25 -0700 (PDT)
Original-Received: from hurd (dsl-141-24.b2b2c.ca. [66.158.141.24])
 by smtp.gmail.com with ESMTPSA id
 h6-20020a0cf406000000b0063c71b62239sm948514qvl.42.2023.10.03.18.42.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 03 Oct 2023 18:42:24 -0700 (PDT)
In-Reply-To: <f8f71dc7-3270-5282-32b7-91a28800b43a@telenet.be> (Maxime Devos's
 message of "Tue, 3 Oct 2023 21:03:21 +0200")
Received-SPF: pass client-ip=2607:f8b0:4864:20::936;
 envelope-from=maxim.cournoyer@gmail.com; helo=mail-ua1-x936.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: guile-devel@gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Developers list for Guile,
 the GNU extensibility library" <guile-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/guile-devel>,
 <mailto:guile-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/guile-devel>
List-Post: <mailto:guile-devel@gnu.org>
List-Help: <mailto:guile-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/guile-devel>,
 <mailto:guile-devel-request@gnu.org?subject=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:22015
Archived-At: <http://permalink.gmane.org/gmane.lisp.guile.devel/22015>

Hello!

Maxime Devos <maximedevos@telenet.be> writes:

> Op 02-10-2023 om 18:13 schreef Maxim Cournoyer:
>>> Something I didn't notice previously:
>>>
>>> Op 25-09-2023 om 16:29 schreef Maxim Cournoyer:
>>>> +  if (scm_is_string (args)) {
>>>> +      /* C code written for 3.9 and earlier expects this function to
>>>> +         take a single argument (the file name).  */
>>>> +      filename = args;
>>>> +      depth = scm_from_int(0);
>>>> +    }
>>> IIUC, args is always a list and never a string.  However, it might be
>>> a list of one element (being a string) or two elements.
>> Surprisingly perhaps, this works, I guess because a string is an array.
>> See the 2009 commit 31ab99de563027fe2bceb60bbd712407fcaf868e which
>> exploits the same feature.
>
> While apparently it works, that does not look like a feature to me but
> rather an accident, though I don't know what hypothetical feature you
> are referring to.

I meant feature here as behavior.

> Also, sure strings are arrays, but you don't seem
> to be using that anywhere, so I'm not following.

That was just an uneducated guess about how the underlying C procedure
translated from the macros.  You can safely forget about it.

>> %load-hook is carefully crafted as to accept both one or two arguments
>> (for backward compatibility).  I didn't pay attention to %load-announce
>> and I'm surprised it's a public API, as its sole function seems to be
>> the default %load-hook value.  
>
> The default value might be, but it's supposed to be overwritable, and
> according to the old API it's a one-argument procedure, so if there is
> an old application/library setting it to something accepting only a
> single argument, there is your API break.

%load-announce is replaced whole via something like:

  set! %load-hook my-proc

placed early in your program.  Whether my-proc is a 1 or 2 arguments
procedure, it works with the proposed change (it's been tested).

> To prevent future API breaks, I propose documenting turning %load-hook
> into a keyword argument procedure with #:allow-other-keys, as
> something like:
>
>   (lambda* (file-name #:key (depth the-default) #:allow-other-keys)
>     ...)
>
> and in the documentation mention that more keywords may be added in
> the future (and hence #:allow-other-keys).
>
> I think it's quite plausible that there will be more such arguments in
> the future!

That sounds like a good idea, helas as I understand, with the current
solution, everything needs to be kept as fixed positional arguments so
we can make sense of them on the C side (which accepts a list of 1 or
more items, expected to be given in order).  So unless you have other
ideas that would also ensure backward-compatibility concern on the C
side, I'd leave it as is for now.

-- 
Thanks,
Maxim