Re: GNU Guile 2.9.9 Released [beta]

2020-01-15 Thread Andy Wingo
On Tue 14 Jan 2020 22:48, Stefan Israelsson Tampe  
writes:

> 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

This is correct, yes.  The declarative bindings optimization makes
toplevel bindings more like letrec bindings, which exposes them to this
other optimization.  My point was that since Guile 2.0, procedure
identity has not been firmly guaranteed in all cases.

Andy



Re: GNU Guile 2.9.9 Released [beta]

2020-01-14 Thread Stefan Israelsson Tampe
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  wrote:

> On Tue 14 Jan 2020 21:13, Stefan Israelsson Tampe 
> 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
>


Re: GNU Guile 2.9.9 Released [beta]

2020-01-14 Thread Andy Wingo
On Tue 14 Jan 2020 21:13, Stefan Israelsson Tampe  
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



Re: GNU Guile 2.9.9 Released [beta]

2020-01-14 Thread Andy Wingo
On Tue 14 Jan 2020 17:03, Mikael Djurfeldt  writes:

> Hmm... it seems like both Stefan and you have interpreted my post
> exactly the opposite way compared to how it was meant. :)

Hah!  My apologies :)

> What I wanted to say is that I probably prefer you to *reverse* the
> recent patch because I prefer to have good optimization also when
> procedures are referenced by value in more than one non-operator
> position. I prefer this over having (eq? p p) => #t for the reasons I
> stated.

I understand this also!  However what Stefan is saying echoes what I've
heard from other people.  There are some cases where eta-converting all
lexical procedure references helps nobody -- it makes (eqv? p p) be
false in places where many people expect it would be true, without
enabling significant optimizations.  In that case, the choice is pretty
clear.  But if there are significant optimizations left on the table, I
would hesitate a lot before chasing an ideal of procedure identity in
cases where the procedure's behavior cannot possibly differ.  Anyway
that's not where we are currently, thankfully!

Cheers,

Andy



Re: GNU Guile 2.9.9 Released [beta]

2020-01-14 Thread Stefan Israelsson Tampe
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.



On Mon, Jan 13, 2020 at 9:39 AM Andy Wingo  wrote:

> We are pleased to announce GNU Guile release 2.9.9.  This is the ninfth
> and probably final pre-release of what will eventually become the 3.0
> release series.
>
> Compared to the current stable series (2.2.x), the future Guile 3.0 adds
> support for just-in-time native code generation, speeding up all Guile
> programs.  See the NEWS extract at the end of the mail for full details.
>
> Compared to the previous prerelease (2.9.7), Guile 2.9.8 fixes a number
> of bugs.
>
> The current plan is to make a 3.0.0 final release on 17 January 2020.
> If there's nothing wrong with this prerelease, 3.0.0 will be essentially
> identical to 2.9.9.  With that in mind, please test and make sure the
> release works on your platform!  Please send any build reports (success
> or failure) to guile-devel@gnu.org, along with platform details.  You
> can file a bug by sending mail to bug-gu...@gnu.org.
>
> The Guile web page is located at http://gnu.org/software/guile/, and
> among other things, it contains a copy of the Guile manual and pointers
> to more resources.
>
> Guile is an implementation of the Scheme programming language, packaged
> for use in a wide variety of environments.  In addition to implementing
> the R5RS, R6RS, and R7RS Scheme standards, Guile includes a module
> system, full access to POSIX system calls, networking support, multiple
> threads, dynamic linking, a foreign function call interface, powerful
> string processing, and HTTP client and server implementations.
>
> Guile can run interactively, as a script interpreter, and as a Scheme
> compiler to VM bytecode.  It is also packaged as a library so that
> applications can easily incorporate a complete Scheme interpreter/VM.
> An application can use Guile as an extension language, a clean and
> powerful configuration language, or as multi-purpose "glue" to connect
> primitives provided by the application.  It is easy to call Scheme code
> From C code and vice versa.  Applications can add new functions, data
> types, control structures, and even syntax to Guile, to create a
> domain-specific language tailored to the task at hand.
>
> Guile 2.9.9 can be installed in parallel with Guile 2.2.x; see
>
> http://www.gnu.org/software/guile/manual/html_node/Parallel-Installations.html
> .
>
> A more detailed NEWS summary follows these details on how to get the
> Guile sources.
>
> Here are the compressed sources:
>   http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.lz   (10MB)
>   http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.xz   (12MB)
>   http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.gz   (21MB)
>
> Here are the GPG detached signatures[*]:
>   http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.lz.sig
>   http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.xz.sig
>   http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.gz.sig
>
> Use a mirror for higher download bandwidth:
>   http://www.gnu.org/order/ftp.html
>
> Here are the SHA256 checksums:
>
>   59f136e5db36eba070cc5e68784e632dc2beae4b21fd6c7c8ed2c598cc992efc
> guile-2.9.9.tar.lz
>   bf71920cfa23e59fc6257bee84ef4dfeccf4f03e96bb8205592e09f9dbff2969
> guile-2.9.9.tar.xz
>   eafe394cf99d9dd1ab837e6d1b9b2b8d9f0cd13bc34e64ca92456ce1bc2b1925
> guile-2.9.9.tar.gz
>
> [*] Use a .sig file to verify that the corresponding file (without the
> .sig suffix) is intact.  First, be sure to download both the .sig file
> and the corresponding tarball.  Then, run a command like this:
>
>   gpg --verify guile-2.9.9.tar.gz.sig
>
> If that command fails because you don't have the required public key,
> then run this command to import it:
>
>   gpg --keyserver keys.gnupg.net --recv-keys
> 4FD4D288D445934E0A14F9A5A8803732E4436885
>
> and rerun the 'gpg --verify' command.
>
> This release was bootstrapped with the following tools:
>   Autoconf 2.69
>   Automake 1.16.1
>   Libtool 2.4.6
>   Gnulib v0.1-1157-gb03f418
>   Makeinfo 6.7
>
> An extract from NEWS follows.
>
>
> Changes since alpha 2.9.8 (since 2.9.7):
>
> * Notable changes
>
> ** `define-module' #:autoload no longer pulls in the whole module
>
> One of the ways that a module can use another is "autoloads".  For
> example:
>
>   (define-module (a) #:autoload (b) (make-b))
>
> In this example, module `(b)' will only be imported when the `make-b'
> identifier is referenced.  However besides the imprecision about when a
> given binding is actually referenced, this mechanism used to cause the
> whole imported module to become available, not just the specified
> bindings.  This has now been changed to only import the specified 

Re: GNU Guile 2.9.9 Released [beta]

2020-01-14 Thread Stefan Israelsson Tampe
I'll apply your patch and see if it works. After reading it more carefully
I think I understand your decrement count. Nice code!

On Tue, Jan 14, 2020 at 5:36 PM Stefan Israelsson Tampe <
stefan.ita...@gmail.com> wrote:

> 1. I don't understand why you decrement the count in operator position
> 2. I don't see that you increase the count when a procedure is returned
> from a lambda
>
> Example
> (define (f a) a)
> (define (g)
> (hash-set! H f 1) ; (*)
> (f 1)) ;(**)
> (define (h)
>(pk (hash-ref H f))) ; (*)
>
> (g)
> (h)
>
> => '(#f) as count in your patch is counted up twice (*) and down ones (**)
> in total count = 1 so you will not maintain the identity of f and you will
> get a bad printout
>
> Then we also have this example
> (define (f a) a)
> (define (u) f)
> (define (g) (hash-set! H (u) 1))
> (define (h) (pk (hash-ref H f)))
>
> (g)
> (h)
> This will again print (#f) as the count will be 1.
>
> /Stefan
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Jan 14, 2020 at 5:16 PM Andy Wingo  wrote:
>
>> On Tue 14 Jan 2020 15:47, Stefan Israelsson Tampe <
>> stefan.ita...@gmail.com> writes:
>>
>> > Yes, your patch is indicating when you should use the same identity
>> > e.g. all uses of procedures in a higher order position such as an
>> > argument or a return value. But I looked at your patch, which looks
>> > good but I saw that for operator position you decrease the count. Why?
>> > Also you are free to use one version in argument / return position and
>> > another one in operator position the only limit is to use the same
>> > identity for on operator position. Finally don't you need to count
>> > usage of returning a variable as well?
>>
>> Not sure what the bug is.  Do you have a test case that shows the
>> behavior that you think is not good?
>>
>> Andy
>>
>


Re: GNU Guile 2.9.9 Released [beta]

2020-01-14 Thread Stefan Israelsson Tampe
I'm not stupid and I don't see any good reason why you cannot maintain a
way to keep function identities. I could go as far as having a primitive to
mark a procedure for keeping the identity.

But No  No, please apply the patch. For example the nice thing with python
on guile is that python functions is also scheme functions and vice versa
without the procedure identity (eq? f f) = #t you will need
to wrap every single scheme call and totally destroy python on guile. It
will be a mess. So I would probably not make a python on guile release for
guile 3.0. Also Not guile log because it also
is highly invested using procedures as hash keys. What I would probably do
is to apply wingos patch and demand other who want guile 3.0 and python on
guile and guile-log to do the same.

Regards
Stefan

On Tue, Jan 14, 2020 at 5:47 PM Mikael Djurfeldt 
wrote:

> It might be reasonable to keep the patch for now in order not to introduce
> novel behavior this short before the 3.0 release.
>
> But especially in light of Andy's work, I do regret introducing
> procedure-properties. It's a more LISPy feature than Schemey. Did you see
> Andy's argument about procedure equality below?
>
> I would have preferred to postpone the release and drop procedure
> equality, procedure-properties etc. It can be handy and convenient, yes,
> but there is a reason why R6RS didn't require (eq? p p) -> #t...
>
> Best regards,
> Mikael
>
> On Tue, Jan 14, 2020 at 5:37 PM Stefan Israelsson Tampe <
> stefan.ita...@gmail.com> wrote:
>
>>
>>
>> -- Forwarded message -
>> From: Stefan Israelsson Tampe 
>> Date: Tue, Jan 14, 2020 at 5:23 PM
>> Subject: Re: GNU Guile 2.9.9 Released [beta]
>> To: Mikael Djurfeldt 
>>
>>
>> This is how it always have been in guile, without this patch you cannot
>> use procedure-property, use a function as a key to hash maps etc. If
>> this patch goes you need to forbid usage
>> of procedures as keys to hashmap, nuke procedure properties and friends
>> or mark it as internal to avoid luring schemers into using a faulty method.
>> This patch improves the use of higher order functions
>> not risk it. For example I often classify functions into different
>> categories and maintain this information as a property on the function via
>> a hashmap. This is a quite natural way of programming. Without it you need
>> to put the procedures in a datastructure and track that datastructure
>> that will uglify a lot of code. It is manageable but when the opposite is
>> similarly speeded code but much nicer and enjoyable code with absolutely no
>> risk in
>> higher order functionality countrary as you state (because higher order
>> worked flawlessly before in guile and the patch is restoring that).
>>
>> On Tue, Jan 14, 2020 at 5:07 PM Mikael Djurfeldt 
>> wrote:
>>
>>> Hmm... it seems like both Stefan and you have interpreted my post
>>> exactly the opposite way compared to how it was meant. :)
>>>
>>> I completely agree that procedure equality is not strongly connected to
>>> the first citizen-ness.
>>>
>>> What I wanted to say is that I probably prefer you to *reverse* the
>>> recent patch because I prefer to have good optimization also when
>>> procedures are referenced by value in more than one non-operator position.
>>> I prefer this over having (eq? p p) => #t for the reasons I stated.
>>>
>>> Best regards,
>>> Mikael
>>>
>>> Den tis 14 jan. 2020 15:33Andy Wingo  skrev:
>>>
>>>> On Tue 14 Jan 2020 13:18, Mikael Djurfeldt 
>>>> writes:
>>>>
>>>> > I probably don't have a clue about what you are talking about (or at
>>>> > least hope so), but this---the "eq change"---sounds scary to me.
>>>> >
>>>> > One of the *strengths* of Scheme is that procedures are first class
>>>> > citizens. As wonderfully show-cased in e.g. SICP this can be used to
>>>> > obtain expressive and concise programs, where procedures can occur
>>>> > many times as values outside operator position.
>>>> >
>>>> > I would certainly *not* want to trade in an important optimization
>>>> > step in those cases to obtain intuitive procedure equality. The risk
>>>> > is then that you would tend to avoid passing around procedures as
>>>> > values.
>>>>
>>>> Is this true?
>>>>
>>>>   (eq? '() '())
>>>>
>>>> What about this?
>>>>
>>>>   (eq? '(a) '(a))
>>>

Re: GNU Guile 2.9.9 Released [beta]

2020-01-14 Thread Taylan Kammer
During the R7RS-small discussion, I remember Will Clinger suggesting to
keep (eqv? proc1 proc2) => #t but unspecifying it for eq?.  Would that
help in Guile's case?  I don't remember the exact optimization he
suggested this for.


- Taylan

On 14.01.2020 17:47, Mikael Djurfeldt wrote:
> It might be reasonable to keep the patch for now in order not to
> introduce novel behavior this short before the 3.0 release.
> 
> But especially in light of Andy's work, I do regret introducing
> procedure-properties. It's a more LISPy feature than Schemey. Did you
> see Andy's argument about procedure equality below?
> 
> I would have preferred to postpone the release and drop procedure
> equality, procedure-properties etc. It can be handy and convenient, yes,
> but there is a reason why R6RS didn't require (eq? p p) -> #t...
> 
> Best regards,
> Mikael
> 
> On Tue, Jan 14, 2020 at 5:37 PM Stefan Israelsson Tampe
> mailto:stefan.ita...@gmail.com>> wrote:
> 
> 
> 
> -- Forwarded message -
> From: *Stefan Israelsson Tampe*  <mailto:stefan.ita...@gmail.com>>
>     Date: Tue, Jan 14, 2020 at 5:23 PM
> Subject: Re: GNU Guile 2.9.9 Released [beta]
> To: Mikael Djurfeldt  <mailto:mik...@djurfeldt.com>>
> 
> 
> This is how it always have been in guile, without this patch you
> cannot use procedure-property, use a function as a key to hash maps
> etc. If this patch goes you need to forbid usage
> of procedures as keys to hashmap, nuke procedure properties and
> friends or mark it as internal to avoid luring schemers into using a
> faulty method. This patch improves the use of higher order functions
> not risk it. For example I often classify functions into different
> categories and maintain this information as a property on the
> function via a hashmap. This is a quite natural way of programming.
> Without it you need
> to put the procedures in a datastructure and track that
> datastructure that will uglify a lot of code. It is manageable but
> when the opposite is similarly speeded code but much nicer and
> enjoyable code with absolutely no risk in
> higher order functionality countrary as you state (because higher
> order worked flawlessly before in guile and the patch is restoring
> that).
> 
> On Tue, Jan 14, 2020 at 5:07 PM Mikael Djurfeldt
> mailto:mik...@djurfeldt.com>> wrote:
> 
> Hmm... it seems like both Stefan and you have interpreted my
> post exactly the opposite way compared to how it was meant. :)
> 
> I completely agree that procedure equality is not strongly
> connected to the first citizen-ness.
> 
> What I wanted to say is that I probably prefer you to *reverse*
> the recent patch because I prefer to have good optimization also
> when procedures are referenced by value in more than one
> non-operator position. I prefer this over having (eq? p p) => #t
> for the reasons I stated.
> 
> Best regards,
> Mikael
> 
> Den tis 14 jan. 2020 15:33Andy Wingo  <mailto:wi...@pobox.com>> skrev:
> 
> On Tue 14 Jan 2020 13:18, Mikael Djurfeldt
> mailto:mik...@djurfeldt.com>> writes:
> 
> > I probably don't have a clue about what you are talking
> about (or at
> > least hope so), but this---the "eq change"---sounds scary
> to me.
> >
> > One of the *strengths* of Scheme is that procedures are
> first class
> > citizens. As wonderfully show-cased in e.g. SICP this can
> be used to
> > obtain expressive and concise programs, where procedures
> can occur
> > many times as values outside operator position.
> >
> > I would certainly *not* want to trade in an important
> optimization
> > step in those cases to obtain intuitive procedure
> equality. The risk
> > is then that you would tend to avoid passing around
> procedures as
> > values.
> 
> Is this true?
> 
>   (eq? '() '())
> 
> What about this?
> 
>   (eq? '(a) '(a))
> 
> And yet, are datums not first-class values?  What does being
> first-class
> have to do with it?
> 
> Does it matter whether it's eq? or eqv?
> 
> What about:
> 
>   (eq? (lambda () 10) (lambda () 10))

Re: GNU Guile 2.9.9 Released [beta]

2020-01-14 Thread Mikael Djurfeldt
It might be reasonable to keep the patch for now in order not to introduce
novel behavior this short before the 3.0 release.

But especially in light of Andy's work, I do regret introducing
procedure-properties. It's a more LISPy feature than Schemey. Did you see
Andy's argument about procedure equality below?

I would have preferred to postpone the release and drop procedure equality,
procedure-properties etc. It can be handy and convenient, yes, but there is
a reason why R6RS didn't require (eq? p p) -> #t...

Best regards,
Mikael

On Tue, Jan 14, 2020 at 5:37 PM Stefan Israelsson Tampe <
stefan.ita...@gmail.com> wrote:

>
>
> -- Forwarded message -
> From: Stefan Israelsson Tampe 
> Date: Tue, Jan 14, 2020 at 5:23 PM
> Subject: Re: GNU Guile 2.9.9 Released [beta]
> To: Mikael Djurfeldt 
>
>
> This is how it always have been in guile, without this patch you cannot
> use procedure-property, use a function as a key to hash maps etc. If
> this patch goes you need to forbid usage
> of procedures as keys to hashmap, nuke procedure properties and friends or
> mark it as internal to avoid luring schemers into using a faulty method.
> This patch improves the use of higher order functions
> not risk it. For example I often classify functions into different
> categories and maintain this information as a property on the function via
> a hashmap. This is a quite natural way of programming. Without it you need
> to put the procedures in a datastructure and track that datastructure that
> will uglify a lot of code. It is manageable but when the opposite is
> similarly speeded code but much nicer and enjoyable code with absolutely no
> risk in
> higher order functionality countrary as you state (because higher order
> worked flawlessly before in guile and the patch is restoring that).
>
> On Tue, Jan 14, 2020 at 5:07 PM Mikael Djurfeldt 
> wrote:
>
>> Hmm... it seems like both Stefan and you have interpreted my post exactly
>> the opposite way compared to how it was meant. :)
>>
>> I completely agree that procedure equality is not strongly connected to
>> the first citizen-ness.
>>
>> What I wanted to say is that I probably prefer you to *reverse* the
>> recent patch because I prefer to have good optimization also when
>> procedures are referenced by value in more than one non-operator position.
>> I prefer this over having (eq? p p) => #t for the reasons I stated.
>>
>> Best regards,
>> Mikael
>>
>> Den tis 14 jan. 2020 15:33Andy Wingo  skrev:
>>
>>> On Tue 14 Jan 2020 13:18, Mikael Djurfeldt 
>>> writes:
>>>
>>> > I probably don't have a clue about what you are talking about (or at
>>> > least hope so), but this---the "eq change"---sounds scary to me.
>>> >
>>> > One of the *strengths* of Scheme is that procedures are first class
>>> > citizens. As wonderfully show-cased in e.g. SICP this can be used to
>>> > obtain expressive and concise programs, where procedures can occur
>>> > many times as values outside operator position.
>>> >
>>> > I would certainly *not* want to trade in an important optimization
>>> > step in those cases to obtain intuitive procedure equality. The risk
>>> > is then that you would tend to avoid passing around procedures as
>>> > values.
>>>
>>> Is this true?
>>>
>>>   (eq? '() '())
>>>
>>> What about this?
>>>
>>>   (eq? '(a) '(a))
>>>
>>> And yet, are datums not first-class values?  What does being first-class
>>> have to do with it?
>>>
>>> Does it matter whether it's eq? or eqv?
>>>
>>> What about:
>>>
>>>   (eq? (lambda () 10) (lambda () 10))
>>>
>>> What's the difference?
>>>
>>> What's the difference in the lambda calculus between "\x.f x" and "f"?
>>>
>>> What if in a partial evaluator, you see a `(eq? x y)`, and you notice
>>> that `x' is bound to a lambda expression?  Can you say anything about
>>> the value of the expression?
>>>
>>> Does comparing procedures for equality mean anything at all?
>>> https://cs-syd.eu/posts/2016-01-17-function-equality-in-haskell
>>>
>>> Anyway :)  All that is a bit of trolling on my part.  What I mean to say
>>> is that instincts are tricky when it comes to object identity, equality,
>>> equivalence, and especially all of those combined with procedures.  The
>>> R6RS (what can be more Schemely than a Scheme standard?) makes this
>>> clear.
>>>
>>> All that said, with the recent patch, I believe that Guile 3.0's
>>> behavior preserves your intuitions.  Bug reports very welcome!
>>>
>>> Andy
>>>
>>


Fwd: GNU Guile 2.9.9 Released [beta]

2020-01-14 Thread Stefan Israelsson Tampe
-- Forwarded message -
From: Stefan Israelsson Tampe 
Date: Tue, Jan 14, 2020 at 5:23 PM
Subject: Re: GNU Guile 2.9.9 Released [beta]
To: Mikael Djurfeldt 


This is how it always have been in guile, without this patch you cannot use
procedure-property, use a function as a key to hash maps etc. If this patch
goes you need to forbid usage
of procedures as keys to hashmap, nuke procedure properties and friends or
mark it as internal to avoid luring schemers into using a faulty method.
This patch improves the use of higher order functions
not risk it. For example I often classify functions into different
categories and maintain this information as a property on the function via
a hashmap. This is a quite natural way of programming. Without it you need
to put the procedures in a datastructure and track that datastructure that
will uglify a lot of code. It is manageable but when the opposite is
similarly speeded code but much nicer and enjoyable code with absolutely no
risk in
higher order functionality countrary as you state (because higher order
worked flawlessly before in guile and the patch is restoring that).

On Tue, Jan 14, 2020 at 5:07 PM Mikael Djurfeldt 
wrote:

> Hmm... it seems like both Stefan and you have interpreted my post exactly
> the opposite way compared to how it was meant. :)
>
> I completely agree that procedure equality is not strongly connected to
> the first citizen-ness.
>
> What I wanted to say is that I probably prefer you to *reverse* the recent
> patch because I prefer to have good optimization also when procedures are
> referenced by value in more than one non-operator position. I prefer this
> over having (eq? p p) => #t for the reasons I stated.
>
> Best regards,
> Mikael
>
> Den tis 14 jan. 2020 15:33Andy Wingo  skrev:
>
>> On Tue 14 Jan 2020 13:18, Mikael Djurfeldt  writes:
>>
>> > I probably don't have a clue about what you are talking about (or at
>> > least hope so), but this---the "eq change"---sounds scary to me.
>> >
>> > One of the *strengths* of Scheme is that procedures are first class
>> > citizens. As wonderfully show-cased in e.g. SICP this can be used to
>> > obtain expressive and concise programs, where procedures can occur
>> > many times as values outside operator position.
>> >
>> > I would certainly *not* want to trade in an important optimization
>> > step in those cases to obtain intuitive procedure equality. The risk
>> > is then that you would tend to avoid passing around procedures as
>> > values.
>>
>> Is this true?
>>
>>   (eq? '() '())
>>
>> What about this?
>>
>>   (eq? '(a) '(a))
>>
>> And yet, are datums not first-class values?  What does being first-class
>> have to do with it?
>>
>> Does it matter whether it's eq? or eqv?
>>
>> What about:
>>
>>   (eq? (lambda () 10) (lambda () 10))
>>
>> What's the difference?
>>
>> What's the difference in the lambda calculus between "\x.f x" and "f"?
>>
>> What if in a partial evaluator, you see a `(eq? x y)`, and you notice
>> that `x' is bound to a lambda expression?  Can you say anything about
>> the value of the expression?
>>
>> Does comparing procedures for equality mean anything at all?
>> https://cs-syd.eu/posts/2016-01-17-function-equality-in-haskell
>>
>> Anyway :)  All that is a bit of trolling on my part.  What I mean to say
>> is that instincts are tricky when it comes to object identity, equality,
>> equivalence, and especially all of those combined with procedures.  The
>> R6RS (what can be more Schemely than a Scheme standard?) makes this
>> clear.
>>
>> All that said, with the recent patch, I believe that Guile 3.0's
>> behavior preserves your intuitions.  Bug reports very welcome!
>>
>> Andy
>>
>


Re: GNU Guile 2.9.9 Released [beta]

2020-01-14 Thread Stefan Israelsson Tampe
1. I don't understand why you decrement the count in operator position
2. I don't see that you increase the count when a procedure is returned
from a lambda

Example
(define (f a) a)
(define (g)
(hash-set! H f 1) ; (*)
(f 1)) ;(**)
(define (h)
   (pk (hash-ref H f))) ; (*)

(g)
(h)

=> '(#f) as count in your patch is counted up twice (*) and down ones (**)
in total count = 1 so you will not maintain the identity of f and you will
get a bad printout

Then we also have this example
(define (f a) a)
(define (u) f)
(define (g) (hash-set! H (u) 1))
(define (h) (pk (hash-ref H f)))

(g)
(h)
This will again print (#f) as the count will be 1.

/Stefan























On Tue, Jan 14, 2020 at 5:16 PM Andy Wingo  wrote:

> On Tue 14 Jan 2020 15:47, Stefan Israelsson Tampe 
> writes:
>
> > Yes, your patch is indicating when you should use the same identity
> > e.g. all uses of procedures in a higher order position such as an
> > argument or a return value. But I looked at your patch, which looks
> > good but I saw that for operator position you decrease the count. Why?
> > Also you are free to use one version in argument / return position and
> > another one in operator position the only limit is to use the same
> > identity for on operator position. Finally don't you need to count
> > usage of returning a variable as well?
>
> Not sure what the bug is.  Do you have a test case that shows the
> behavior that you think is not good?
>
> Andy
>


Re: GNU Guile 2.9.9 Released [beta]

2020-01-14 Thread Andy Wingo
On Tue 14 Jan 2020 15:47, Stefan Israelsson Tampe  
writes:

> Yes, your patch is indicating when you should use the same identity
> e.g. all uses of procedures in a higher order position such as an
> argument or a return value. But I looked at your patch, which looks
> good but I saw that for operator position you decrease the count. Why?
> Also you are free to use one version in argument / return position and
> another one in operator position the only limit is to use the same
> identity for on operator position. Finally don't you need to count
> usage of returning a variable as well?

Not sure what the bug is.  Do you have a test case that shows the
behavior that you think is not good?

Andy



Re: GNU Guile 2.9.9 Released [beta]

2020-01-14 Thread Mikael Djurfeldt
Hmm... it seems like both Stefan and you have interpreted my post exactly
the opposite way compared to how it was meant. :)

I completely agree that procedure equality is not strongly connected to the
first citizen-ness.

What I wanted to say is that I probably prefer you to *reverse* the recent
patch because I prefer to have good optimization also when procedures are
referenced by value in more than one non-operator position. I prefer this
over having (eq? p p) => #t for the reasons I stated.

Best regards,
Mikael

Den tis 14 jan. 2020 15:33Andy Wingo  skrev:

> On Tue 14 Jan 2020 13:18, Mikael Djurfeldt  writes:
>
> > I probably don't have a clue about what you are talking about (or at
> > least hope so), but this---the "eq change"---sounds scary to me.
> >
> > One of the *strengths* of Scheme is that procedures are first class
> > citizens. As wonderfully show-cased in e.g. SICP this can be used to
> > obtain expressive and concise programs, where procedures can occur
> > many times as values outside operator position.
> >
> > I would certainly *not* want to trade in an important optimization
> > step in those cases to obtain intuitive procedure equality. The risk
> > is then that you would tend to avoid passing around procedures as
> > values.
>
> Is this true?
>
>   (eq? '() '())
>
> What about this?
>
>   (eq? '(a) '(a))
>
> And yet, are datums not first-class values?  What does being first-class
> have to do with it?
>
> Does it matter whether it's eq? or eqv?
>
> What about:
>
>   (eq? (lambda () 10) (lambda () 10))
>
> What's the difference?
>
> What's the difference in the lambda calculus between "\x.f x" and "f"?
>
> What if in a partial evaluator, you see a `(eq? x y)`, and you notice
> that `x' is bound to a lambda expression?  Can you say anything about
> the value of the expression?
>
> Does comparing procedures for equality mean anything at all?
> https://cs-syd.eu/posts/2016-01-17-function-equality-in-haskell
>
> Anyway :)  All that is a bit of trolling on my part.  What I mean to say
> is that instincts are tricky when it comes to object identity, equality,
> equivalence, and especially all of those combined with procedures.  The
> R6RS (what can be more Schemely than a Scheme standard?) makes this
> clear.
>
> All that said, with the recent patch, I believe that Guile 3.0's
> behavior preserves your intuitions.  Bug reports very welcome!
>
> Andy
>


Re: GNU Guile 2.9.9 Released [beta]

2020-01-14 Thread Stefan Israelsson Tampe
Yes, your patch is indicating when you should use the same identity e.g.
all uses of procedures in a higher order position such as an argument or a
return
value. But I looked at your patch, which looks good but I saw that for
operator position you decrease the count. Why? Also you are free to use one
version in
argument / return position and another one in operator position the only
limit is to use the same identity for on operator position. Finally don't
you need to count
usage of returning a variable as well?

On Tue, Jan 14, 2020 at 3:34 PM Andy Wingo  wrote:

> On Tue 14 Jan 2020 13:18, Mikael Djurfeldt  writes:
>
> > I probably don't have a clue about what you are talking about (or at
> > least hope so), but this---the "eq change"---sounds scary to me.
> >
> > One of the *strengths* of Scheme is that procedures are first class
> > citizens. As wonderfully show-cased in e.g. SICP this can be used to
> > obtain expressive and concise programs, where procedures can occur
> > many times as values outside operator position.
> >
> > I would certainly *not* want to trade in an important optimization
> > step in those cases to obtain intuitive procedure equality. The risk
> > is then that you would tend to avoid passing around procedures as
> > values.
>
> Is this true?
>
>   (eq? '() '())
>
> What about this?
>
>   (eq? '(a) '(a))
>
> And yet, are datums not first-class values?  What does being first-class
> have to do with it?
>
> Does it matter whether it's eq? or eqv?
>
> What about:
>
>   (eq? (lambda () 10) (lambda () 10))
>
> What's the difference?
>
> What's the difference in the lambda calculus between "\x.f x" and "f"?
>
> What if in a partial evaluator, you see a `(eq? x y)`, and you notice
> that `x' is bound to a lambda expression?  Can you say anything about
> the value of the expression?
>
> Does comparing procedures for equality mean anything at all?
> https://cs-syd.eu/posts/2016-01-17-function-equality-in-haskell
>
> Anyway :)  All that is a bit of trolling on my part.  What I mean to say
> is that instincts are tricky when it comes to object identity, equality,
> equivalence, and especially all of those combined with procedures.  The
> R6RS (what can be more Schemely than a Scheme standard?) makes this
> clear.
>
> All that said, with the recent patch, I believe that Guile 3.0's
> behavior preserves your intuitions.  Bug reports very welcome!
>
> Andy
>
>


RE: GNU Guile 2.9.9 Released [beta]

2020-01-14 Thread dsmich


> We are pleased to announce GNU Guile release 2.9.9.

When attempting to build on a Debian Jessie 32bit arm system, gcc
(Debian 4.9.2-10+deb8u2) 4.9.2

I'm working on updating this system to Debian Stable, but it might
require wiping it and doing a fresh install.

-Dale


make  all-recursive
make[1]: Entering directory '/home/dsmith/src/guile-2.9.9'
Making all in lib
make[2]: Entering directory '/home/dsmith/src/guile-2.9.9/lib'
make  all-recursive
make[3]: Entering directory '/home/dsmith/src/guile-2.9.9/lib'
make[4]: Entering directory '/home/dsmith/src/guile-2.9.9/lib'
make[4]: Nothing to be done for 'all-am'.
make[4]: Leaving directory '/home/dsmith/src/guile-2.9.9/lib'
make[3]: Leaving directory '/home/dsmith/src/guile-2.9.9/lib'
make[2]: Leaving directory '/home/dsmith/src/guile-2.9.9/lib'
Making all in meta
make[2]: Entering directory '/home/dsmith/src/guile-2.9.9/meta'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/dsmith/src/guile-2.9.9/meta'
Making all in libguile
make[2]: Entering directory '/home/dsmith/src/guile-2.9.9/libguile'
make  all-am
make[3]: Entering directory '/home/dsmith/src/guile-2.9.9/libguile'
  CC   libguile_3.0_la-jit.lo
jit.c:232:1: error: initializer element is not constant
 static const jit_gpr_t THREAD = JIT_V0;
 ^
jit.c:237:1: error: initializer element is not constant
 static const jit_gpr_t SP = JIT_R0;
 ^
jit.c:243:1: error: initializer element is not constant
 static const jit_gpr_t FP = JIT_R1;
 ^
jit.c:248:1: error: initializer element is not constant
 static const jit_gpr_t OLD_FP_FOR_RETURN_TRAMPOLINE = JIT_V1; /* T0 */
 ^
jit.c:251:1: error: initializer element is not constant
 static const jit_gpr_t T0 = JIT_V1;
 ^
jit.c:252:1: error: initializer element is not constant
 static const jit_gpr_t T1 = JIT_V2;
 ^
jit.c:253:1: error: initializer element is not constant
 static const jit_gpr_t T2 = JIT_R2;
 ^
jit.c:254:1: error: initializer element is not constant
 SCM_UNUSED static const jit_gpr_t T3_OR_FP = JIT_R1;
 ^
jit.c:255:1: error: initializer element is not constant
 SCM_UNUSED static const jit_gpr_t T4_OR_SP = JIT_R0;
 ^
jit.c:259:1: error: initializer element is not constant
 SCM_UNUSED static const jit_gpr_t T0_PRESERVED = JIT_V1;
 ^
jit.c:260:1: error: initializer element is not constant
 static const jit_gpr_t T1_PRESERVED = JIT_V2;
 ^
jit.c:974:1: warning: 'sp_u64_operand' defined but not used [-Wunused-function]
 sp_u64_operand (scm_jit_state *j, uint32_t slot)
 ^
jit.c:1028:1: warning: 'sp_s32_operand' defined but not used [-Wunused-function]
 sp_s32_operand (scm_jit_state *j, uint32_t src)
 ^
Makefile:3126: recipe for target 'libguile_3.0_la-jit.lo' failed
make[3]: *** [libguile_3.0_la-jit.lo] Error 1
  CC   libguile_3.0_la-keywords.lo
  CC   libguile_3.0_la-list.lo
  CC   libguile_3.0_la-load.lo
  CC   libguile_3.0_la-loader.lo
  CC   libguile_3.0_la-macros.lo
  CC   libguile_3.0_la-mallocs.lo
  CC   libguile_3.0_la-memoize.lo
  CC   libguile_3.0_la-modules.lo
  CC   libguile_3.0_la-null-threads.lo
  CC   libguile_3.0_la-numbers.lo
  CC   libguile_3.0_la-objprop.lo
  CC   libguile_3.0_la-options.lo
  CC   libguile_3.0_la-pairs.lo
  CC   libguile_3.0_la-poll.lo
  CC   libguile_3.0_la-ports.lo
  CC   libguile_3.0_la-print.lo
  CC   libguile_3.0_la-procprop.lo
  CC   libguile_3.0_la-procs.lo
  CC   libguile_3.0_la-programs.lo
  CC   libguile_3.0_la-promises.lo
  CC   libguile_3.0_la-r6rs-ports.lo
  CC   libguile_3.0_la-random.lo
  CC   libguile_3.0_la-rdelim.lo
  CC   libguile_3.0_la-read.lo
  CC   libguile_3.0_la-rw.lo
  CC   libguile_3.0_la-scmsigs.lo
  CC   libguile_3.0_la-script.lo
  CC   libguile_3.0_la-simpos.lo
  CC   libguile_3.0_la-smob.lo
  CC   libguile_3.0_la-sort.lo
  CC   libguile_3.0_la-srcprop.lo
  CC   libguile_3.0_la-srfi-1.lo
  CC   libguile_3.0_la-srfi-4.lo
  CC   libguile_3.0_la-srfi-13.lo
  CC   libguile_3.0_la-srfi-14.lo
  CC   libguile_3.0_la-srfi-60.lo
  CC   libguile_3.0_la-stackchk.lo
  CC   libguile_3.0_la-stacks.lo
  CC   libguile_3.0_la-stime.lo
  CC   libguile_3.0_la-strings.lo
  CC   libguile_3.0_la-strorder.lo
  CC   libguile_3.0_la-strports.lo
  CC   libguile_3.0_la-struct.lo
  CC   libguile_3.0_la-symbols.lo
  CC   libguile_3.0_la-syntax.lo
  CC   libguile_3.0_la-threads.lo
  CC   libguile_3.0_la-throw.lo
  CC   libguile_3.0_la-trees.lo
  CC   libguile_3.0_la-unicode.lo
  CC   libguile_3.0_la-uniform.lo
  CC   libguile_3.0_la-values.lo
  CC   libguile_3.0_la-variable.lo
  CC   libguile_3.0_la-vectors.lo
  CC   libguile_3.0_la-version.lo
  CC   libguile_3.0_la-vm.lo
In file included from ../libguile/pairs.h:26:0,
 from alist.h:26,
 from vm.c:38:
vm-engine.c: In function 'vm_regular_engine':

Re: GNU Guile 2.9.9 Released [beta]

2020-01-14 Thread Andy Wingo
On Tue 14 Jan 2020 13:18, Mikael Djurfeldt  writes:

> I probably don't have a clue about what you are talking about (or at
> least hope so), but this---the "eq change"---sounds scary to me.
>
> One of the *strengths* of Scheme is that procedures are first class
> citizens. As wonderfully show-cased in e.g. SICP this can be used to
> obtain expressive and concise programs, where procedures can occur
> many times as values outside operator position.
>
> I would certainly *not* want to trade in an important optimization
> step in those cases to obtain intuitive procedure equality. The risk
> is then that you would tend to avoid passing around procedures as
> values.

Is this true?

  (eq? '() '())

What about this?

  (eq? '(a) '(a))

And yet, are datums not first-class values?  What does being first-class
have to do with it?

Does it matter whether it's eq? or eqv?

What about:

  (eq? (lambda () 10) (lambda () 10))

What's the difference?

What's the difference in the lambda calculus between "\x.f x" and "f"?

What if in a partial evaluator, you see a `(eq? x y)`, and you notice
that `x' is bound to a lambda expression?  Can you say anything about
the value of the expression?

Does comparing procedures for equality mean anything at all?
https://cs-syd.eu/posts/2016-01-17-function-equality-in-haskell

Anyway :)  All that is a bit of trolling on my part.  What I mean to say
is that instincts are tricky when it comes to object identity, equality,
equivalence, and especially all of those combined with procedures.  The
R6RS (what can be more Schemely than a Scheme standard?) makes this
clear.

All that said, with the recent patch, I believe that Guile 3.0's
behavior preserves your intuitions.  Bug reports very welcome!

Andy



Re: GNU Guile 2.9.9 Released [beta]

2020-01-14 Thread Stefan Israelsson Tampe
I agree about the scary part as it e.g. would make it impossible to use
procedures in hashmaps (where my trouble stems from) in any sane way, I
know how to fix
my code but there will be a lot of anger on the mailinglist and irc to
teach how to avoid the problems.

Fortunately probably the next release will have fixes to this and we will
regain the identity features.

Also it is scary that scheme spec allows compilers to abuse the usage of
procedure identities.





On Tue, Jan 14, 2020 at 1:18 PM Mikael Djurfeldt 
wrote:

> Dear Andy,
>
> I probably don't have a clue about what you are talking about (or at least
> hope so), but this---the "eq change"---sounds scary to me.
>
> One of the *strengths* of Scheme is that procedures are first class
> citizens. As wonderfully show-cased in e.g. SICP this can be used to obtain
> expressive and concise programs, where procedures can occur many times as
> values outside operator position.
>
> I would certainly *not* want to trade in an important optimization step in
> those cases to obtain intuitive procedure equality. The risk is then that
> you would tend to avoid passing around procedures as values.
>
> Have I misunderstood something or do I have a point here?
>
> Best regards,
> Mikael
>
> Den tis 14 jan. 2020 12:18Andy Wingo  skrev:
>
>> On Mon 13 Jan 2020 22:32, Stefan Israelsson Tampe <
>> stefan.ita...@gmail.com> writes:
>>
>> > In current guile (eq? f f) = #f for a procedure f. Try:
>>
>> Note that procedure equality is explicitly unspecified by R6RS.  Guile's
>> declarative modules optimization took advantage of this to eta-expand
>> references to declaratively-bound top-level lambda expressions.  This
>> unlocks the "well-known" closure optimizations: closure elision,
>> contification, and so on.
>>
>> However, the intention with the eta expansion was really to prevent the
>>
>>   (module-add! mod 'foo foo)
>>
>> from making the procedure not-well-known.  If that's the only reference
>> to `foo' outside the operator position, procedure identity for `foo' is
>> kept, because it's only accessed outside the module.  But then I
>> realized thanks to your mail (and the three or four times that people
>> stumbled against this beforehand) that we can preserve the optimizations
>> and peoples' intuitions about procedure equality if we restrict
>> eta-expansion to those procedures that are only referenced by value in
>> at most a single position.
>>
>> It would be best to implement the eta-expansion after peval; doing it
>> where we do leaves some optimization opportunities on the table.  But I
>> have implemented this change in git and it should fix this issue.
>>
>> Comparative benchmark results:
>>
>>
>> https://wingolog.org/pub/guile-2.9.7-vs-guile-2.9.9-with-eq-change-microbenchmarks.png
>>
>> Regards,
>>
>> Andy
>>
>>


Re: GNU Guile 2.9.9 Released [beta]

2020-01-14 Thread Mikael Djurfeldt
Dear Andy,

I probably don't have a clue about what you are talking about (or at least
hope so), but this---the "eq change"---sounds scary to me.

One of the *strengths* of Scheme is that procedures are first class
citizens. As wonderfully show-cased in e.g. SICP this can be used to obtain
expressive and concise programs, where procedures can occur many times as
values outside operator position.

I would certainly *not* want to trade in an important optimization step in
those cases to obtain intuitive procedure equality. The risk is then that
you would tend to avoid passing around procedures as values.

Have I misunderstood something or do I have a point here?

Best regards,
Mikael

Den tis 14 jan. 2020 12:18Andy Wingo  skrev:

> On Mon 13 Jan 2020 22:32, Stefan Israelsson Tampe 
> writes:
>
> > In current guile (eq? f f) = #f for a procedure f. Try:
>
> Note that procedure equality is explicitly unspecified by R6RS.  Guile's
> declarative modules optimization took advantage of this to eta-expand
> references to declaratively-bound top-level lambda expressions.  This
> unlocks the "well-known" closure optimizations: closure elision,
> contification, and so on.
>
> However, the intention with the eta expansion was really to prevent the
>
>   (module-add! mod 'foo foo)
>
> from making the procedure not-well-known.  If that's the only reference
> to `foo' outside the operator position, procedure identity for `foo' is
> kept, because it's only accessed outside the module.  But then I
> realized thanks to your mail (and the three or four times that people
> stumbled against this beforehand) that we can preserve the optimizations
> and peoples' intuitions about procedure equality if we restrict
> eta-expansion to those procedures that are only referenced by value in
> at most a single position.
>
> It would be best to implement the eta-expansion after peval; doing it
> where we do leaves some optimization opportunities on the table.  But I
> have implemented this change in git and it should fix this issue.
>
> Comparative benchmark results:
>
>
> https://wingolog.org/pub/guile-2.9.7-vs-guile-2.9.9-with-eq-change-microbenchmarks.png
>
> Regards,
>
> Andy
>
>


Fwd: GNU Guile 2.9.9 Released [beta]

2020-01-14 Thread Stefan Israelsson Tampe
-- Forwarded message -
From: Stefan Israelsson Tampe 
Date: Tue, Jan 14, 2020 at 12:43 PM
Subject: Re: GNU Guile 2.9.9 Released [beta]
To: Andy Wingo 


Thanks!

Phew!

I think that for an f, a direct function application need not to be counted
as a position. Only when you use f in a higher order manner
demands that you count this. E.g. (g f), (return f)

Regards
Stefan

On Tue, Jan 14, 2020 at 12:16 PM Andy Wingo  wrote:

> On Mon 13 Jan 2020 22:32, Stefan Israelsson Tampe 
> writes:
>
> > In current guile (eq? f f) = #f for a procedure f. Try:
>
> Note that procedure equality is explicitly unspecified by R6RS.  Guile's
> declarative modules optimization took advantage of this to eta-expand
> references to declaratively-bound top-level lambda expressions.  This
> unlocks the "well-known" closure optimizations: closure elision,
> contification, and so on.
>
> However, the intention with the eta expansion was really to prevent the
>
>   (module-add! mod 'foo foo)
>
> from making the procedure not-well-known.  If that's the only reference
> to `foo' outside the operator position, procedure identity for `foo' is
> kept, because it's only accessed outside the module.  But then I
> realized thanks to your mail (and the three or four times that people
> stumbled against this beforehand) that we can preserve the optimizations
> and peoples' intuitions about procedure equality if we restrict
> eta-expansion to those procedures that are only referenced by value in
> at most a single position.
>
> It would be best to implement the eta-expansion after peval; doing it
> where we do leaves some optimization opportunities on the table.  But I
> have implemented this change in git and it should fix this issue.
>
> Comparative benchmark results:
>
>
> https://wingolog.org/pub/guile-2.9.7-vs-guile-2.9.9-with-eq-change-microbenchmarks.png
>
> Regards,
>
> Andy
>


Re: GNU Guile 2.9.9 Released [beta]

2020-01-14 Thread Andy Wingo
On Mon 13 Jan 2020 22:32, Stefan Israelsson Tampe  
writes:

> In current guile (eq? f f) = #f for a procedure f. Try:

Note that procedure equality is explicitly unspecified by R6RS.  Guile's
declarative modules optimization took advantage of this to eta-expand
references to declaratively-bound top-level lambda expressions.  This
unlocks the "well-known" closure optimizations: closure elision,
contification, and so on.

However, the intention with the eta expansion was really to prevent the

  (module-add! mod 'foo foo)

from making the procedure not-well-known.  If that's the only reference
to `foo' outside the operator position, procedure identity for `foo' is
kept, because it's only accessed outside the module.  But then I
realized thanks to your mail (and the three or four times that people
stumbled against this beforehand) that we can preserve the optimizations
and peoples' intuitions about procedure equality if we restrict
eta-expansion to those procedures that are only referenced by value in
at most a single position.

It would be best to implement the eta-expansion after peval; doing it
where we do leaves some optimization opportunities on the table.  But I
have implemented this change in git and it should fix this issue.

Comparative benchmark results:

  
https://wingolog.org/pub/guile-2.9.7-vs-guile-2.9.9-with-eq-change-microbenchmarks.png

Regards,

Andy



Re: GNU Guile 2.9.9 Released [beta]

2020-01-14 Thread Stefan Israelsson Tampe
Note that the problem I have is that procedure-property and hash-table code
with procedure key's fail on me due to the fact that the identity of
functions varies in a non clear way.


On Mon, Jan 13, 2020 at 10:32 PM Stefan Israelsson Tampe <
stefan.ita...@gmail.com> wrote:

> Nice, but I think we are not there yet.
>
> In current guile (eq? f f) = #f for a procedure f. Try:
>
> (define-module (b)
>   #:export (f))
>
> (define (g x) x)
> (define (u x) g)
> (define (f x)
>   (pk eq?(eq?  g (u x)))
>   (pk eqv?   (eqv? g (u x)))
>   (pk equal? (equal? g (u x)))
>   (pk (object-address g) (object-address (u x
>
> scheme@(guile-user)> (use-modules (b))
> ;;; note: source file /home/stis/b.scm
> ;;;   newer than compiled
> /home/stis/.cache/guile/ccache/3.0-LE-8-4.2/home/stis/
> b.scm.go
> ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
> ;;;   or pass the --no-auto-compile argument to disable.
> ;;; compiling /home/stis/b.scm
> ;;; compiled
> /home/stis/.cache/guile/ccache/3.0-LE-8-4.2/home/stis/b.scm.go
> scheme@(guile-user)> (f 1)
>
> ;;; (# #f)
>
> ;;; (# #f)
>
> ;;; (# #f)
>
> ;;; (139824931374184 139824931374200)
>
>
> On Mon, Jan 13, 2020 at 9:39 AM Andy Wingo  wrote:
>
>> We are pleased to announce GNU Guile release 2.9.9.  This is the ninfth
>> and probably final pre-release of what will eventually become the 3.0
>> release series.
>>
>> Compared to the current stable series (2.2.x), the future Guile 3.0 adds
>> support for just-in-time native code generation, speeding up all Guile
>> programs.  See the NEWS extract at the end of the mail for full details.
>>
>> Compared to the previous prerelease (2.9.7), Guile 2.9.8 fixes a number
>> of bugs.
>>
>> The current plan is to make a 3.0.0 final release on 17 January 2020.
>> If there's nothing wrong with this prerelease, 3.0.0 will be essentially
>> identical to 2.9.9.  With that in mind, please test and make sure the
>> release works on your platform!  Please send any build reports (success
>> or failure) to guile-devel@gnu.org, along with platform details.  You
>> can file a bug by sending mail to bug-gu...@gnu.org.
>>
>> The Guile web page is located at http://gnu.org/software/guile/, and
>> among other things, it contains a copy of the Guile manual and pointers
>> to more resources.
>>
>> Guile is an implementation of the Scheme programming language, packaged
>> for use in a wide variety of environments.  In addition to implementing
>> the R5RS, R6RS, and R7RS Scheme standards, Guile includes a module
>> system, full access to POSIX system calls, networking support, multiple
>> threads, dynamic linking, a foreign function call interface, powerful
>> string processing, and HTTP client and server implementations.
>>
>> Guile can run interactively, as a script interpreter, and as a Scheme
>> compiler to VM bytecode.  It is also packaged as a library so that
>> applications can easily incorporate a complete Scheme interpreter/VM.
>> An application can use Guile as an extension language, a clean and
>> powerful configuration language, or as multi-purpose "glue" to connect
>> primitives provided by the application.  It is easy to call Scheme code
>> From C code and vice versa.  Applications can add new functions, data
>> types, control structures, and even syntax to Guile, to create a
>> domain-specific language tailored to the task at hand.
>>
>> Guile 2.9.9 can be installed in parallel with Guile 2.2.x; see
>>
>> http://www.gnu.org/software/guile/manual/html_node/Parallel-Installations.html
>> .
>>
>> A more detailed NEWS summary follows these details on how to get the
>> Guile sources.
>>
>> Here are the compressed sources:
>>   http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.lz   (10MB)
>>   http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.xz   (12MB)
>>   http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.gz   (21MB)
>>
>> Here are the GPG detached signatures[*]:
>>   http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.lz.sig
>>   http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.xz.sig
>>   http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.gz.sig
>>
>> Use a mirror for higher download bandwidth:
>>   http://www.gnu.org/order/ftp.html
>>
>> Here are the SHA256 checksums:
>>
>>   59f136e5db36eba070cc5e68784e632dc2beae4b21fd6c7c8ed2c598cc992efc
>> guile-2.9.9.tar.lz
>>   bf71920cfa23e59fc6257bee84ef4dfeccf4f03e96bb8205592e09f9dbff2969
>> guile-2.9.9.tar.xz
>>   eafe394cf99d9dd1ab837e6d1b9b2b8d9f0cd13bc34e64ca92456ce1bc2b1925
>> guile-2.9.9.tar.gz
>>
>> [*] Use a .sig file to verify that the corresponding file (without the
>> .sig suffix) is intact.  First, be sure to download both the .sig file
>> and the corresponding tarball.  Then, run a command like this:
>>
>>   gpg --verify guile-2.9.9.tar.gz.sig
>>
>> If that command fails because you don't have the required public key,
>> then run this command to import it:
>>
>>   gpg --keyserver keys.gnupg.net --recv-keys
>> 4FD4D288D445934E0A14F9A5A8803732E4436885
>>
>> and rerun the 'gpg 

Re: bug#39118: GNU Guile 2.9.9 Released [beta]

2020-01-13 Thread John Cowan
Okay, with GUILE_JIT_THRESHOLD set to -1 in the environment, I can build
Guile under Cygwin.  There are two test failures which probably reflect
differences between newlib and glibc:

ERROR: time.test: strptime: GNU %s format: strftime fr_FR.utf8 - arguments:
((system-error "strptime" "~A" ("Invalid argument") (22)))
ERROR: time.test: strptime: GNU %s format: strftime fr_FR.iso88591 -
arguments: ((system-error "strptime" "~A" ("Invalid argument") (22)))

And that's that: Cygwin can support Guile 3.0 without JIT.  It might be a
good idea to force this variable on in "configure" when building under
Cygwin.


Re: GNU Guile 2.9.9 Released [beta]

2020-01-13 Thread Stefan Israelsson Tampe
I mean that this bug is for 2.9.9

On Mon, Jan 13, 2020 at 10:32 PM Stefan Israelsson Tampe <
stefan.ita...@gmail.com> wrote:

> Nice, but I think we are not there yet.
>
> In current guile (eq? f f) = #f for a procedure f. Try:
>
> (define-module (b)
>   #:export (f))
>
> (define (g x) x)
> (define (u x) g)
> (define (f x)
>   (pk eq?(eq?  g (u x)))
>   (pk eqv?   (eqv? g (u x)))
>   (pk equal? (equal? g (u x)))
>   (pk (object-address g) (object-address (u x
>
> scheme@(guile-user)> (use-modules (b))
> ;;; note: source file /home/stis/b.scm
> ;;;   newer than compiled
> /home/stis/.cache/guile/ccache/3.0-LE-8-4.2/home/stis/
> b.scm.go
> ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
> ;;;   or pass the --no-auto-compile argument to disable.
> ;;; compiling /home/stis/b.scm
> ;;; compiled
> /home/stis/.cache/guile/ccache/3.0-LE-8-4.2/home/stis/b.scm.go
> scheme@(guile-user)> (f 1)
>
> ;;; (# #f)
>
> ;;; (# #f)
>
> ;;; (# #f)
>
> ;;; (139824931374184 139824931374200)
>
>
> On Mon, Jan 13, 2020 at 9:39 AM Andy Wingo  wrote:
>
>> We are pleased to announce GNU Guile release 2.9.9.  This is the ninfth
>> and probably final pre-release of what will eventually become the 3.0
>> release series.
>>
>> Compared to the current stable series (2.2.x), the future Guile 3.0 adds
>> support for just-in-time native code generation, speeding up all Guile
>> programs.  See the NEWS extract at the end of the mail for full details.
>>
>> Compared to the previous prerelease (2.9.7), Guile 2.9.8 fixes a number
>> of bugs.
>>
>> The current plan is to make a 3.0.0 final release on 17 January 2020.
>> If there's nothing wrong with this prerelease, 3.0.0 will be essentially
>> identical to 2.9.9.  With that in mind, please test and make sure the
>> release works on your platform!  Please send any build reports (success
>> or failure) to guile-devel@gnu.org, along with platform details.  You
>> can file a bug by sending mail to bug-gu...@gnu.org.
>>
>> The Guile web page is located at http://gnu.org/software/guile/, and
>> among other things, it contains a copy of the Guile manual and pointers
>> to more resources.
>>
>> Guile is an implementation of the Scheme programming language, packaged
>> for use in a wide variety of environments.  In addition to implementing
>> the R5RS, R6RS, and R7RS Scheme standards, Guile includes a module
>> system, full access to POSIX system calls, networking support, multiple
>> threads, dynamic linking, a foreign function call interface, powerful
>> string processing, and HTTP client and server implementations.
>>
>> Guile can run interactively, as a script interpreter, and as a Scheme
>> compiler to VM bytecode.  It is also packaged as a library so that
>> applications can easily incorporate a complete Scheme interpreter/VM.
>> An application can use Guile as an extension language, a clean and
>> powerful configuration language, or as multi-purpose "glue" to connect
>> primitives provided by the application.  It is easy to call Scheme code
>> From C code and vice versa.  Applications can add new functions, data
>> types, control structures, and even syntax to Guile, to create a
>> domain-specific language tailored to the task at hand.
>>
>> Guile 2.9.9 can be installed in parallel with Guile 2.2.x; see
>>
>> http://www.gnu.org/software/guile/manual/html_node/Parallel-Installations.html
>> .
>>
>> A more detailed NEWS summary follows these details on how to get the
>> Guile sources.
>>
>> Here are the compressed sources:
>>   http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.lz   (10MB)
>>   http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.xz   (12MB)
>>   http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.gz   (21MB)
>>
>> Here are the GPG detached signatures[*]:
>>   http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.lz.sig
>>   http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.xz.sig
>>   http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.gz.sig
>>
>> Use a mirror for higher download bandwidth:
>>   http://www.gnu.org/order/ftp.html
>>
>> Here are the SHA256 checksums:
>>
>>   59f136e5db36eba070cc5e68784e632dc2beae4b21fd6c7c8ed2c598cc992efc
>> guile-2.9.9.tar.lz
>>   bf71920cfa23e59fc6257bee84ef4dfeccf4f03e96bb8205592e09f9dbff2969
>> guile-2.9.9.tar.xz
>>   eafe394cf99d9dd1ab837e6d1b9b2b8d9f0cd13bc34e64ca92456ce1bc2b1925
>> guile-2.9.9.tar.gz
>>
>> [*] Use a .sig file to verify that the corresponding file (without the
>> .sig suffix) is intact.  First, be sure to download both the .sig file
>> and the corresponding tarball.  Then, run a command like this:
>>
>>   gpg --verify guile-2.9.9.tar.gz.sig
>>
>> If that command fails because you don't have the required public key,
>> then run this command to import it:
>>
>>   gpg --keyserver keys.gnupg.net --recv-keys
>> 4FD4D288D445934E0A14F9A5A8803732E4436885
>>
>> and rerun the 'gpg --verify' command.
>>
>> This release was bootstrapped with the following tools:
>>   Autoconf 2.69
>>   Automake 1.16.1
>>   Libtool 2.4.6
>>   Gnulib 

Re: GNU Guile 2.9.9 Released [beta]

2020-01-13 Thread Stefan Israelsson Tampe
Nice, but I think we are not there yet.

In current guile (eq? f f) = #f for a procedure f. Try:

(define-module (b)
  #:export (f))

(define (g x) x)
(define (u x) g)
(define (f x)
  (pk eq?(eq?  g (u x)))
  (pk eqv?   (eqv? g (u x)))
  (pk equal? (equal? g (u x)))
  (pk (object-address g) (object-address (u x

scheme@(guile-user)> (use-modules (b))
;;; note: source file /home/stis/b.scm
;;;   newer than compiled
/home/stis/.cache/guile/ccache/3.0-LE-8-4.2/home/stis/
b.scm.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling /home/stis/b.scm
;;; compiled /home/stis/.cache/guile/ccache/3.0-LE-8-4.2/home/stis/b.scm.go
scheme@(guile-user)> (f 1)

;;; (# #f)

;;; (# #f)

;;; (# #f)

;;; (139824931374184 139824931374200)


On Mon, Jan 13, 2020 at 9:39 AM Andy Wingo  wrote:

> We are pleased to announce GNU Guile release 2.9.9.  This is the ninfth
> and probably final pre-release of what will eventually become the 3.0
> release series.
>
> Compared to the current stable series (2.2.x), the future Guile 3.0 adds
> support for just-in-time native code generation, speeding up all Guile
> programs.  See the NEWS extract at the end of the mail for full details.
>
> Compared to the previous prerelease (2.9.7), Guile 2.9.8 fixes a number
> of bugs.
>
> The current plan is to make a 3.0.0 final release on 17 January 2020.
> If there's nothing wrong with this prerelease, 3.0.0 will be essentially
> identical to 2.9.9.  With that in mind, please test and make sure the
> release works on your platform!  Please send any build reports (success
> or failure) to guile-devel@gnu.org, along with platform details.  You
> can file a bug by sending mail to bug-gu...@gnu.org.
>
> The Guile web page is located at http://gnu.org/software/guile/, and
> among other things, it contains a copy of the Guile manual and pointers
> to more resources.
>
> Guile is an implementation of the Scheme programming language, packaged
> for use in a wide variety of environments.  In addition to implementing
> the R5RS, R6RS, and R7RS Scheme standards, Guile includes a module
> system, full access to POSIX system calls, networking support, multiple
> threads, dynamic linking, a foreign function call interface, powerful
> string processing, and HTTP client and server implementations.
>
> Guile can run interactively, as a script interpreter, and as a Scheme
> compiler to VM bytecode.  It is also packaged as a library so that
> applications can easily incorporate a complete Scheme interpreter/VM.
> An application can use Guile as an extension language, a clean and
> powerful configuration language, or as multi-purpose "glue" to connect
> primitives provided by the application.  It is easy to call Scheme code
> From C code and vice versa.  Applications can add new functions, data
> types, control structures, and even syntax to Guile, to create a
> domain-specific language tailored to the task at hand.
>
> Guile 2.9.9 can be installed in parallel with Guile 2.2.x; see
>
> http://www.gnu.org/software/guile/manual/html_node/Parallel-Installations.html
> .
>
> A more detailed NEWS summary follows these details on how to get the
> Guile sources.
>
> Here are the compressed sources:
>   http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.lz   (10MB)
>   http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.xz   (12MB)
>   http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.gz   (21MB)
>
> Here are the GPG detached signatures[*]:
>   http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.lz.sig
>   http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.xz.sig
>   http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.gz.sig
>
> Use a mirror for higher download bandwidth:
>   http://www.gnu.org/order/ftp.html
>
> Here are the SHA256 checksums:
>
>   59f136e5db36eba070cc5e68784e632dc2beae4b21fd6c7c8ed2c598cc992efc
> guile-2.9.9.tar.lz
>   bf71920cfa23e59fc6257bee84ef4dfeccf4f03e96bb8205592e09f9dbff2969
> guile-2.9.9.tar.xz
>   eafe394cf99d9dd1ab837e6d1b9b2b8d9f0cd13bc34e64ca92456ce1bc2b1925
> guile-2.9.9.tar.gz
>
> [*] Use a .sig file to verify that the corresponding file (without the
> .sig suffix) is intact.  First, be sure to download both the .sig file
> and the corresponding tarball.  Then, run a command like this:
>
>   gpg --verify guile-2.9.9.tar.gz.sig
>
> If that command fails because you don't have the required public key,
> then run this command to import it:
>
>   gpg --keyserver keys.gnupg.net --recv-keys
> 4FD4D288D445934E0A14F9A5A8803732E4436885
>
> and rerun the 'gpg --verify' command.
>
> This release was bootstrapped with the following tools:
>   Autoconf 2.69
>   Automake 1.16.1
>   Libtool 2.4.6
>   Gnulib v0.1-1157-gb03f418
>   Makeinfo 6.7
>
> An extract from NEWS follows.
>
>
> Changes since alpha 2.9.8 (since 2.9.7):
>
> * Notable changes
>
> ** `define-module' #:autoload no longer pulls in the whole module
>
> One of the ways that a module can use another is "autoloads".  For
> 

Re: GNU Guile 2.9.9 Released [beta]

2020-01-13 Thread John Cowan
Guile 2.9.9, like .8 and .7, does not build on Cygwin (64 bit).  Configure
runs without error, but make crashes with this (truncated to just the tail):

Making all in bootstrap
make[2]: Entering directory
'/cygdrive/c/Users/rr828893/Downloads/guile-2.9.9/bootstrap'
  BOOTSTRAP GUILEC ice-9/eval.go
  BOOTSTRAP GUILEC ice-9/psyntax-pp.go
  BOOTSTRAP GUILEC language/cps/intmap.go
  BOOTSTRAP GUILEC language/cps/intset.go
  BOOTSTRAP GUILEC language/cps/graphs.go
  BOOTSTRAP GUILEC ice-9/vlist.go
  BOOTSTRAP GUILEC srfi/srfi-1.go
/bin/sh: line 6:  4294 Segmentation fault  (core dumped)
GUILE_AUTO_COMPILE=0 ../meta/build-env guild compile
--target="x86_64-unknown-cygwin" -O1 -Oresolve-primitives -L
"/home/rr828893/Downloads/guile-2.9.9/module" -L
"/home/rr828893/Downloads/guile-2.9.9/guile-readline" -o "srfi/srfi-1.go"
"../module/srfi/srfi-1.scm"
make[2]: *** [Makefile:1930: srfi/srfi-1.go] Error 139
make[2]: Leaving directory
'/cygdrive/c/Users/rr828893/Downloads/guile-2.9.9/bootstrap'
make[1]: *** [Makefile:1849: all-recursive] Error 1
make[1]: Leaving directory
'/cygdrive/c/Users/rr828893/Downloads/guile-2.9.9'
make: *** [Makefile:1735: all] Error 2

All previous problems (which were easy to work around) have gone away in
this release, which is progress, but it doesn't get me past Guile 2.2.



John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
Your worships will perhaps be thinking that it is an easy thing
to blow up a dog? [Or] to write a book?
--Don Quixote, Introduction


Re: GNU Guile 2.9.9 Released [beta]

2020-01-13 Thread Andy Wingo
On Mon 13 Jan 2020 09:39, Andy Wingo  writes:

> Compared to the previous prerelease (2.9.7), Guile 2.9.8 fixes a number
> of bugs.

Obviously this was meant to be 2.9.9 versus 2.9.8 :)

> Changes since alpha 2.9.8 (since 2.9.7):

Here too :)



GNU Guile 2.9.9 Released [beta]

2020-01-13 Thread Andy Wingo
We are pleased to announce GNU Guile release 2.9.9.  This is the ninfth
and probably final pre-release of what will eventually become the 3.0
release series.

Compared to the current stable series (2.2.x), the future Guile 3.0 adds
support for just-in-time native code generation, speeding up all Guile
programs.  See the NEWS extract at the end of the mail for full details.

Compared to the previous prerelease (2.9.7), Guile 2.9.8 fixes a number
of bugs.

The current plan is to make a 3.0.0 final release on 17 January 2020.
If there's nothing wrong with this prerelease, 3.0.0 will be essentially
identical to 2.9.9.  With that in mind, please test and make sure the
release works on your platform!  Please send any build reports (success
or failure) to guile-devel@gnu.org, along with platform details.  You
can file a bug by sending mail to bug-gu...@gnu.org.

The Guile web page is located at http://gnu.org/software/guile/, and
among other things, it contains a copy of the Guile manual and pointers
to more resources.

Guile is an implementation of the Scheme programming language, packaged
for use in a wide variety of environments.  In addition to implementing
the R5RS, R6RS, and R7RS Scheme standards, Guile includes a module
system, full access to POSIX system calls, networking support, multiple
threads, dynamic linking, a foreign function call interface, powerful
string processing, and HTTP client and server implementations.

Guile can run interactively, as a script interpreter, and as a Scheme
compiler to VM bytecode.  It is also packaged as a library so that
applications can easily incorporate a complete Scheme interpreter/VM.
An application can use Guile as an extension language, a clean and
powerful configuration language, or as multi-purpose "glue" to connect
primitives provided by the application.  It is easy to call Scheme code
>From C code and vice versa.  Applications can add new functions, data
types, control structures, and even syntax to Guile, to create a
domain-specific language tailored to the task at hand.

Guile 2.9.9 can be installed in parallel with Guile 2.2.x; see
http://www.gnu.org/software/guile/manual/html_node/Parallel-Installations.html.

A more detailed NEWS summary follows these details on how to get the
Guile sources.

Here are the compressed sources:
  http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.lz   (10MB)
  http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.xz   (12MB)
  http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.gz   (21MB)

Here are the GPG detached signatures[*]:
  http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.lz.sig
  http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.xz.sig
  http://alpha.gnu.org/gnu/guile/guile-2.9.9.tar.gz.sig

Use a mirror for higher download bandwidth:
  http://www.gnu.org/order/ftp.html

Here are the SHA256 checksums:

  59f136e5db36eba070cc5e68784e632dc2beae4b21fd6c7c8ed2c598cc992efc  
guile-2.9.9.tar.lz
  bf71920cfa23e59fc6257bee84ef4dfeccf4f03e96bb8205592e09f9dbff2969  
guile-2.9.9.tar.xz
  eafe394cf99d9dd1ab837e6d1b9b2b8d9f0cd13bc34e64ca92456ce1bc2b1925  
guile-2.9.9.tar.gz

[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify guile-2.9.9.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

  gpg --keyserver keys.gnupg.net --recv-keys 
4FD4D288D445934E0A14F9A5A8803732E4436885

and rerun the 'gpg --verify' command.

This release was bootstrapped with the following tools:
  Autoconf 2.69
  Automake 1.16.1
  Libtool 2.4.6
  Gnulib v0.1-1157-gb03f418
  Makeinfo 6.7

An extract from NEWS follows.


Changes since alpha 2.9.8 (since 2.9.7):

* Notable changes

** `define-module' #:autoload no longer pulls in the whole module

One of the ways that a module can use another is "autoloads".  For
example:

  (define-module (a) #:autoload (b) (make-b))

In this example, module `(b)' will only be imported when the `make-b'
identifier is referenced.  However besides the imprecision about when a
given binding is actually referenced, this mechanism used to cause the
whole imported module to become available, not just the specified
bindings.  This has now been changed to only import the specified bindings.

This is a backward-incompatible change.  The fix is to mention all
bindings of interest in the autoload clause.  Feedback is welcome.

** `guard' no longer unwinds the stack for clause tests

SRFI-34, and then R6RS and R7RS, defines a `guard' form that is a
shorthand for `with-exception-handler'.  The cond-like clauses for the
exception handling are specified to run with the continuation of the
`guard', while any re-propagation of the exception happens with the
continuation of the original `raise'.

In practice, this means that one needs full `call-with-continuation' to
implement the specified semantics, to be able to unwind the