From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Maxim Cournoyer 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> <87v8bn5fk1.fsf@gmail.com> 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 Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Wed Oct 11 04:37:26 2023 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 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 ) 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 ) 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 ) 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 ; 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: (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" 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:22025 Archived-At: Hi Maxime, Maxime Devos 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