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, 10 Oct 2023 22:36:34 -0400
Message-ID: <87r0m1evgt.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>
 <87v8bn5fk1.fsf@gmail.com>
 <c03b3c3b-c4d1-1e29-a278-51848ed1a967@telenet.be>
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="21974"; mail-complaints-to="usenet@ciao.gmane.io"
User-Agent: Gnus/5.13 (Gnus v5.13)
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 11 04:37:26 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 1qqP6D-0005U8-PC
	for guile-devel@m.gmane-mx.org; Wed, 11 Oct 2023 04:37:25 +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 1qqP5V-00085Q-29; Tue, 10 Oct 2023 22:36:41 -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 1qqP5T-00085G-Hv
 for guile-devel@gnu.org; Tue, 10 Oct 2023 22:36:39 -0400
Original-Received: from mail-qk1-x736.google.com ([2607:f8b0:4864:20::736])
 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 1qqP5R-0003S5-NH
 for guile-devel@gnu.org; Tue, 10 Oct 2023 22:36:39 -0400
Original-Received: by mail-qk1-x736.google.com with SMTP id
 af79cd13be357-775751c35d4so404967285a.0
 for <guile-devel@gnu.org>; Tue, 10 Oct 2023 19:36:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1696991796; x=1697596596; darn=gnu.org;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
 :message-id:reply-to;
 bh=6hqzsh2Yvp8x1F0RwlywzLAw4McDF7hv8h/ro9VbLko=;
 b=bD1VyVwBtWQQezIgwxK6E+bDxl0T9hx+AxNE+JnIw+/AGXPgpSq9QX9jo2PA3Yq4F1
 RiM8E5Yr5lJjYcZPUVLJh5YxOa4gYuh7yhe4fqlj84vNAPlXD5Ni0Y7Lm/svrscxxmdM
 8PBoTkrA7DGbLb8OSalqm9iXzBhCiNTnzmEvofp8YKibjWKrtVQAhHjn+izsBLOiBQ6R
 KAAvwmtdG1vh7CQTmzJ1/qbpKxOjADr4ZXJ9OoMzut/C5qufe3h4LxJjTP5SwFBIUowc
 nx2lgmn/AxjhmBgOnPANlDR3mTeusrdS0JKGgw6YzwNDbM4jLHIzlINa/Tj/BD53e3wO
 PbBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1696991796; x=1697596596;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
 :to:cc:subject:date:message-id:reply-to;
 bh=6hqzsh2Yvp8x1F0RwlywzLAw4McDF7hv8h/ro9VbLko=;
 b=o9C6a+rdlUmnfksSWP/OBktdZOkg+SWhdokNTJO7YmzxGHbOSm4vRg95APEoYa8+j5
 UsIVwaB9H5Gq2fFG5WgvW3wLM+Zac/jaJ618+2UQkZta68wiS8a1ub6mQwToCTgihZj3
 D+ADNsycY8v5H8gk47dD7Zih0PHLj3qe9cdMrmpL3eM8Y1OcxWYwtUEYaBLp/tEkwDyc
 ac3DcauKg0uiS3iKQQ1YWLhvy5JxnrvjKObL+kJ1bK8SCfnPO7WlMebhBPJFDdnj7STS
 zZw9UaXXBjujmW4E6vmPaCQY/54LAcDfHZNQv0yg/ilym86Qo7aHYKhY/tpJCukhD+yd
 9k4w==
X-Gm-Message-State: AOJu0Yxail+ZvRWAui32rrtINVncHzVHD4PWetaeyrnD6A8A/k3IGfBa
 UeGg6sYWYxcrXvOoXmsJHL3AGbqIq5LHQA==
X-Google-Smtp-Source: AGHT+IFhncN8SYdp7vmI/A2fYM5yL/UDEZ7CQFekgbjgb79pC5OdhocQSV3jrKeeoT3RFPmmXNto2Q==
X-Received: by 2002:a05:620a:450b:b0:777:326d:83de with SMTP id
 t11-20020a05620a450b00b00777326d83demr1678195qkp.56.1696991796323; 
 Tue, 10 Oct 2023 19:36:36 -0700 (PDT)
Original-Received: from hurd (dsl-10-149-16.b2b2c.ca. [72.10.149.16])
 by smtp.gmail.com with ESMTPSA id
 vq2-20020a05620a558200b0076f058f5834sm4838485qkn.61.2023.10.10.19.36.35
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Oct 2023 19:36:35 -0700 (PDT)
In-Reply-To: <c03b3c3b-c4d1-1e29-a278-51848ed1a967@telenet.be> (Maxime Devos's
 message of "Tue, 10 Oct 2023 23:29:16 +0200")
Received-SPF: pass client-ip=2607:f8b0:4864:20::736;
 envelope-from=maxim.cournoyer@gmail.com; helo=mail-qk1-x736.google.com
X-Spam_score_int: 6
X-Spam_score: 0.6
X-Spam_bar: /
X-Spam_report: (0.6 / 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,
 GUARANTEED_100_PERCENT=2.699, RCVD_IN_DNSWL_NONE=-0.0001, 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" <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:22025
Archived-At: <http://permalink.gmane.org/gmane.lisp.guile.devel/22025>

Hi Maxime,

Maxime Devos <maximedevos@telenet.be> writes:

[...]

> I now see:
>
>> +  /* For compatibility with older load hooks procedures, fall-back to
>> +     calling it with a single argument if calling it with two fails. */
>> +  scm_internal_catch (scm_from_latin1_symbol ("wrong-number-of-args"),
>> +                      call_hook_2_body, &args_data,
>> +                      call_hook_1_handler, &args_data);
>
> But that doesn't work properly, as it catches too much -- the
> 'wrong-numer-of-args' might be caused by something inside the handler
> instead of an incorrect-arity invocation of the handler itself.
>
> Something like 'program-arity' would be more accurate, albeit not 100%
> guaranteed.  But for backwards compatibility it might be good enough.
> (Caveat: I don't know if uncompiled procedures have arity information,
> though perhaps you could go =E2=80=98no arity information -> assume new
> interface'.)
>
> (On the C level, there is scm_i_procedure_arity.)

I see what you mean about potential nested wrong-number-of-args being
raised by the hook procedure itself, but I'm not sure how that can be
improved.  I had tried introspecting the arity of a procedure and it
didn't work on the C side, at least using 'scm_procedure_minimum_arity'
(which is implemented in terms of scm_i_procedure_arity).  From my
#guile IRC logs:

--8<---------------cut here---------------start------------->8---
2023-09-08 21:13:50	apteryx	interesting, arity =3D scm_procedure_minimum_ar=
ity (hook); doesn't work in load.c
2023-09-08 21:14:03	apteryx	it produces arity=3D(0 0 #t)
--8<---------------cut here---------------end--------------->8---

Also, what do you mean by 'not 100% guaranteed' ?  I think catching too
many errors here is a better trade than catching none.

>>> 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
>
> The C side doesn't expect anything -- the C side only _calls_ the load
> hook, it doesn't implement the load hook, as far as I can tell.
>
> More concretely, as I understand it, all you need to do on the C-side
> is replacing
>
>> +  scm_call_2(hook, full_filename, depth);
>
> by
>
>> +  scm_call_3(hook, full_filename,  scm_from_utf8_keyword("depth"),
>   depth);
>
> (using SCM_KEYWORD instead might be preferred).

Thanks for the concrete example.  I think I was thinking in terms of
scm_primitive_load, which is the one carrying the extra information
provided to the %load-hook (e.g. the depth) during its recursive calls.
Since we're stuck with positional arguments for scm_primitive_load for
backward compatibility, I see little value having a more flexible arity
for the %load-hook (they will have to evolve together if they do, as I
see it).

So while it sounds good "on paper", in practice it appears it'd provide
little value, unless I'm missing something.  Or did you have concrete
ideas of what extra arguments may make sense to have for a %load-hook
procedure that wouldn't need to be passed through a modified
scm_primitive_load procedure?

Thanks for your continued feedback.

--=20
Maxim