unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Stefan Israelsson Tampe <stefan.itampe@gmail.com>
To: Andy Wingo <wingo@pobox.com>
Cc: Guile User <guile-user@gnu.org>, guile-devel <guile-devel@gnu.org>
Subject: Re: GNU Guile 2.9.9 Released [beta]
Date: Tue, 14 Jan 2020 22:48:58 +0100	[thread overview]
Message-ID: <CAGua6m29Xij9v64LOV1rZ=m4H-EYZ+Q7ERvArFL+5tqb5wvhug@mail.gmail.com> (raw)
In-Reply-To: <875zhdhh5m.fsf@pobox.com>

I have a fix for this by pushing the method idiom to another module. So it
is not a burning issue.

Strange that I did not dee this error before in the 2.x series ever. Isn't
it so that
for procedures define in a (let () ...) the case you are
mentioning happened before but
I was on the impression that no inlining was done for defines on
different places in the
module before

I also have a request to be able to silence warning of unbound variables
that is not so for e.g. a python
implementation. Previously I modded message.scm and compile.scm so that I
can add symbols that will not
issue a warning when compiling.

It consists of

(define %dont-warn-list (make-fluid '()))

;; Exported
(define %add-to-warn-list
  (lambda (sym)
    (fluid-set! (M %dont-warn-list)
                (cons sym
                      (fluid-ref
                       (M %dont-warn-list))))))

And inside the warning emitter one checks for matches in the don't warn
list and mute if it matches.

For this to work we need also change the compiler as in compile.scm (see
the %dont-warn-list line ...

(define-set-C compile-file
  (lambda* (file #:key
                 (output-file      #f)
                 (from             ((C default-language)   file))
                 (to               'bytecode)
                 (env              ((C default-environment) from))
                 (opts             '())
                 (canonicalization 'relative))

    (with-fluids (((C %in-compile                     )   #t               )
 ((C %in-file                        )   file             )
                  ((@@ (system base message) %dont-warn-list)
                                                          '()              )
                  ((C %file-port-name-canonicalization)   canonicalization )
                  ((C %current-file%                  )   file))


It would also be fabulous to direct the compiler depeneding on extensions
of the file which is also something I have to make the python environment
nicer.






On Tue, Jan 14, 2020 at 10:17 PM Andy Wingo <wingo@pobox.com> wrote:

> On Tue 14 Jan 2020 21:13, Stefan Israelsson Tampe <stefan.itampe@gmail.com>
> writes:
>
> > Okey, here is another case that fails with the patch that prevents
> identity misses for toplevels e.g we need similar fixes for anonymous
> functions.
> >
> > (define-module (b)
> >   #:export (q))
> >
> > (define h (make-hash-table))
> > (define (method f)
> >   (hash-set! h f 1)
> >   f)
> > (define q (method (lambda x x)))
> >
> > (pk (hash-ref h q))
> >
> > This fails with (#f)
> >
> > I solved this in my code by placing the method function in another
> module.
>
> Interestingly, this case is not really related to the declarative
> bindings optimization, letrectification, or other things.  It's the same
> as:
>
>   (let ((h (make-hash-table)))
>     (define (method f)
>       (hash-set! h f 1)
>       f)
>     (let* ((q (let ((f (lambda x x)))
>                 (method f))))
>       (pk (hash-ref h q))))
>
> I.e. no top-level bindings are needed.  This prints #f in releases as
> old as 2.0.14 and probably older :)  It optimizes as:
>
>   (let* ((h (make-hash-table))
>          (q (begin
>               (hash-set! h (lambda x x) 1)
>               (lambda x x))))
>     (pk (hash-ref h q)))
>
> So, not a recent change.  Of course we can discuss whether it's the
> right thing or not!
>
> Andy
>


  reply	other threads:[~2020-01-14 21:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-13  8:39 GNU Guile 2.9.9 Released [beta] Andy Wingo
2020-01-13  8:44 ` Andy Wingo
2020-01-13 13:41 ` Zelphir Kaltstahl
2020-01-13 21:32 ` Stefan Israelsson Tampe
2020-01-13 21:33   ` Stefan Israelsson Tampe
2020-01-14  9:57   ` Stefan Israelsson Tampe
2020-01-14 20:13 ` Stefan Israelsson Tampe
2020-01-14 21:17   ` Andy Wingo
2020-01-14 21:48     ` Stefan Israelsson Tampe [this message]
2020-01-15 19:58       ` Andy Wingo
  -- strict thread matches above, loose matches on Subject: below --
2020-01-14 14:39 dsmich

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='CAGua6m29Xij9v64LOV1rZ=m4H-EYZ+Q7ERvArFL+5tqb5wvhug@mail.gmail.com' \
    --to=stefan.itampe@gmail.com \
    --cc=guile-devel@gnu.org \
    --cc=guile-user@gnu.org \
    --cc=wingo@pobox.com \
    /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).