unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Skyler Ferris via "Developers list for Guile, the GNU extensibility library" <guile-devel@gnu.org>
To: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
Cc: "Skyler Ferris via \"Developers list for Guile,
	the GNU extensibility library\"" <guile-devel@gnu.org>,
	Maxime Devos <maximedevos@telenet.be>
Subject: Re: yeRemoving program-arities export
Date: Thu, 09 Jan 2025 09:53:24 +0000	[thread overview]
Message-ID: <4DvFlbTmUeeHimWXHamdSYjxV23C_JyK4VPXP8y4YnHB4-GGaxYIP6V-3rfMImcyOzpYWr1b52NcxE4R0n_we5pfEsZ1XV4Cp77pWfwKH7M=@skyler-ferris.me> (raw)
In-Reply-To: <87ldvlawg0.fsf@web.de>

> Given that the program-arity / program-arities is documented, the more
> pressing problem is that programs using it would be broken right now.
> People may be holding off from updating Guile because they don’t have
> the time to investigate breakage in programs that are working perfectly
> fine in the old version. Which is the typical case for useful tools.
> 
> The worst user experience is seeing a working program break when
> updating a dependency: if the docs are wrong, you’re still in the
> context of your tool, but if it breaks on update, all that context has
> been flushed out already — often years ago.

Fair point. A lot of projects transition APIs by providing deprecation notices, but I am not aware of Guile doing that for this API. This is a strong argument against removing it immediately.
 
> Is it viable to wrap the procedure and exactly preserve the API, so
> existing programs keep working? If it’s a bit slower, that should not
> cause pain (because hardware and Guile got faster in the meantime) but
> it should not break.

I believe this is possible so long as these programs do not need to access arity information from procedures which pass the "primitive-code?" predicate. I am not sure what this predicate is actually testing. The implementation of "is_primitive_code" in "libguile/programs.c" is looking at a list of "code_arena" structs which I am not familiar with. The implementation of "find-program-arities" in "module/system/vm/debug.scm" is searching through loaded ELF images to find the one which contains the given program (and always fails to find one when the program passes "primitive-code?"). Based on the commit message in 27337b6373954e1a975d97d0bf06b5c03d65b64d, it seems like this behavior is expected. What puzzles me the most is that functions defined at the scheme level in the same file are not consistent in whether or not they are primitive. For example, "count" in SRFI 1 is primitive but "unzip1" is not. My best guess is that it has something to do with JIT compiled functions, but that truly is a guess.

Also, I have not looked at the output of "arity:start" and "arity:end". I'm not sure how I would go about testing these, but it looks like the struct returned from "find-program-arities" contains the same information. This procedure also has an optional "context" argument; I have only tried using the default value.

This is the code I'm currently using to try things out. The final line produces a lot of output, you can just comment it out for a quieter script.

(use-modules (system vm debug) (system vm program))

(define program-module (resolve-module '(system vm program)))

(module-set! program-module 'program-arities
  (compose find-program-arities program-code))

(module-set! program-module 'arity:start             arity-low-pc)
(module-set! program-module 'arity:end               arity-high-pc)
(module-set! program-module 'arity:nreq              arity-nreq)
(module-set! program-module 'arity:nopt              arity-nopt)
(module-set! program-module 'arity:rest?             arity-has-rest?)
(module-set! program-module 'arity:kw                arity-keyword-args)
(module-set! program-module 'arity:allow-other-keys? arity-allow-other-keys?)

(define* (uut req #:optional opt0 opt1
                  #:key key0 key1 key2
                  #:allow-other-keys
                  #:rest rest)
  (cons* req opt0 opt1 key0 key1 key2 rest))

(define arities (program-arities uut))
(define arity   (program-arity uut #f))

(format #t "Number of arities:  ~s~%" (length                  arities))
(format #t "Required arguments: ~s~%" (arity:nreq              arity))
(format #t "Optional arguments: ~s~%" (arity:nopt              arity))
(format #t "Rest argmuent?      ~s~%" (arity:rest?             arity))
(format #t "Keyword arguments:  ~s~%" (arity:kw                arity))
(format #t "Other keys?         ~s~%" (arity:allow-other-keys? arity))
(newline)

(define uut
  (case-lambda
    ((single) single)
    ((du o) (list du o))
    ((tr i o) (list tr i o))))

(format #t "Arities from a case-lambda: ~s~%" (length (program-arities uut)))
(newline)

(define (generate-arity-trier proc)
  (lambda (sym var)
    (let ((val (variable-ref var)))
      (when (procedure? val)
        (format #t "Arities of ~s: ~s~a~%"
                sym
                (and=> (proc val) length)
                (if (primitive-code? (program-code val)) " (primitive)" ""))))))

; use any of the below procedures in module-for-each line at the end
(define try-program-arity (generate-arity-trier program-arities))
(define try-program-arguments-alist (generate-arity-trier program-arguments-alist))

(define (check-for-inconsistency sym var)
  (let ((val (variable-ref var)))
    (when (and (procedure?      val)
               (program-arities val)
               (primitive-code? (program-code val)))
      (format #t "~s is inconsistent!~%" sym))))

(module-for-each try-program-arity (resolve-interface '(srfi srfi-1)))




  reply	other threads:[~2025-01-09  9:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-29 11:16 Removing program-arities export Skyler via Developers list for Guile, the GNU extensibility library
2025-01-05 18:07 ` Maxime Devos
2025-01-06 11:01   ` Skyler via Developers list for Guile, the GNU extensibility library
2025-01-08 11:23     ` Skyler Ferris via Developers list for Guile, the GNU extensibility library
2025-01-08 20:21       ` yeRemoving " Dr. Arne Babenhauserheide
2025-01-09  9:53         ` Skyler Ferris via Developers list for Guile, the GNU extensibility library [this message]
2025-01-15  8:44         ` Skyler Ferris via Developers list for Guile, the GNU extensibility library
2025-01-15  9:47       ` Removing " Maxime Devos
2025-01-15 11:10         ` Skyler Ferris via Developers list for Guile, the GNU extensibility library

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='4DvFlbTmUeeHimWXHamdSYjxV23C_JyK4VPXP8y4YnHB4-GGaxYIP6V-3rfMImcyOzpYWr1b52NcxE4R0n_we5pfEsZ1XV4Cp77pWfwKH7M=@skyler-ferris.me' \
    --to=guile-devel@gnu.org \
    --cc=arne_bab@web.de \
    --cc=dev@skyler-ferris.me \
    --cc=maximedevos@telenet.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).