Re: GNU Guile 2.9.9 Released [beta]
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]
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]
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]
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]
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]
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]
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]
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]
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 >>> >>
Re: GNU Guile 2.9.9 Released [beta]
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]
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]
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]
> 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]
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]
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]
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 > >
Re: GNU Guile 2.9.9 Released [beta]
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]
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: GNU Guile 2.9.9 Released [beta]
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]
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]
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]
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 :)
