unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: "Linus Björnstam" <linus.internet@fastmail.se>
To: "Tomas Volf" <~@wolfsden.cz>
Cc: guile-user@gnu.org
Subject: Re: warning: possibly unused local top-level variable `%foo?-procedure'
Date: Fri, 07 Jun 2024 09:26:08 +0200	[thread overview]
Message-ID: <a5b537a5-6595-4fe1-bfd8-c3e619190f29@app.fastmail.com> (raw)
In-Reply-To: <ZmI9mUNgiV9pnBeS@ws>

Thank you for making me realize I use guile-master...

I am not really sure what that binding expands into, but it is reasonable to think it has no effect on performance 

-- 
  Linus Björnstam

On Fri, 7 Jun 2024, at 00:52, Tomas Volf wrote:
> On 2024-06-06 22:02:50 +0200, Linus Björnstam wrote:
>> Which version are you using? All my similar issues with srfi-9 went away last year when srfi things were marked maybe-unused.
>
> I am using the latest 3.0.9.  However thanks to your hint about maybe-unused, I
> can see this:
>
>     $ git log v3.0.9.. -- module/srfi/srfi-9.scm
>     commit 7fef214f6e0df4004020fec530e808c476f2d2bf
>     Author: Andy Wingo <wingo@pobox.com>
>     Date:   Sun Mar 17 09:52:49 2024 +0100
>
>         Remove vestigial code from srfi-9
>
>         * module/srfi/srfi-9.scm (%define-record-type): No need to define
>         record-layout.
>
>     commit 19c7969fff223f28cad90e21ae04a0a5852901fc
>     Author: Andy Wingo <wingo@pobox.com>
>     Date:   Thu Aug 24 11:41:15 2023 +0200
>
>         define-inlinable marks residualized procedure as maybe-unused
>
>         * module/ice-9/boot-9.scm (define-inlinable):
>         * module/srfi/srfi-9.scm (define-tagged-inlinable): Add maybe-unused
>         declaration.  Also require at least one body expr, otherwise the
>         metadata declaration could escape as the proc body.
>
> So it looks like this is not in any released version yet.  And indeed, when I
> try to compile it using the current master, the warning goes away.
>
> I wonder how to work around it in the mean time.  I guess I could just put
> %foo?-procedure as a top-level expression.  This seems to not produce any
> warnings:
>
>     (define-module (x)
>       #:use-module (srfi srfi-9)
>       #:export (<foo>
>                 foo?
>                 make-foo))
>
>     (define-record-type <foo> (make-foo) foo?)
>     %foo?-procedure
>
> I guess there should be pretty much zero performance impact, correct?  Are there
> any side effects I might not be aware of?
>
>>
>> I don't have a computer this week so I cannot try your code. Sorry.
>
> No worries, you were helpful already, enjoy your no-computer time :)
>
>>
>> --
>>   Linus Björnstam
>>
>> On Wed, 5 Jun 2024, at 17:02, Tomas Volf wrote:
>> > Hello,
>> >
>> > I am getting following warning from a guild compile:
>> >
>> >     warning: possibly unused local top-level variable `%foo?-procedure'
>> >
>> > And I am not sure how to tackle it.  This is my full source code:
>> >
>> >     (define-module (x)
>> >       #:use-module (srfi srfi-9)
>> >       #:export (<foo>
>> >                 foo?
>> >                 make-foo))
>> >
>> >     (define-record-type <foo> (make-foo) foo?)
>> >
>> > When I try to compile it:
>> >
>> >     $ guild compile -W 3 -o x.go x.scm
>> >     x.scm:7:0: warning: possibly unused local top-level variable
>> > `%foo?-procedure'
>> >     wrote `x.go'
>> >
>> > I would (for obvious reasons) like to keep my compilation warning-free.  I can
>> > think of two approaches:
>> >
>> > 1. Export the %foo?-procedure
>> >      I think this would confuse downstream users, since they are not expected to
>> >      use it directly.
>> >
>> > 2. Mark the procedure as used
>> >       In C I could use `(void)proc;', is there an equivalent of that construct
>> >       in Guile?
>> >
>> > Are there other options?  How are you approaching it?
>> >
>> > Thank you and have a nice day,
>> > Tomas Volf
>> >
>> > PS: I am not even sure why this warning happens, the `foo?' syntax transformer
>> > is exported and *does* reference it (as far as I can tell from ,expand).
>> >
>> > --
>> > There are only two hard things in Computer Science:
>> > cache invalidation, naming things and off-by-one errors.
>> >
>> > Attachments:
>> > * signature.asc
>
> Have a nice day,
> Tomas Volf
>
> --
> There are only two hard things in Computer Science:
> cache invalidation, naming things and off-by-one errors.
>
> Attachments:
> * signature.asc



      reply	other threads:[~2024-06-07  7:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-05 15:02 warning: possibly unused local top-level variable `%foo?-procedure' Tomas Volf
2024-06-06 20:02 ` Linus Björnstam
2024-06-06 22:52   ` Tomas Volf
2024-06-07  7:26     ` Linus Björnstam [this message]

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=a5b537a5-6595-4fe1-bfd8-c3e619190f29@app.fastmail.com \
    --to=linus.internet@fastmail.se \
    --cc=guile-user@gnu.org \
    --cc=~@wolfsden.cz \
    /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).