[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Guile 3.0.0 released

From: Linus Björnstam
Subject: Re: GNU Guile 3.0.0 released
Date: Sun, 19 Jan 2020 13:07:25 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

If you want a portable implementation, you can actually hack it using macros. Re-define lambda, define, let(*,-values,letrec,letrec*),cond, case and begin to rewrite everything to letrec and you are done! The problem is that it will be slower than using let* for the bindings that don't require letrec in many schemes, since the don't do the equivilent of guile's letrectification pass (described in the paper "Letrec done right (reloaded)" iirc).

I have a syntax-rules implementation of it if you are interested, that also supports a simplified define-like binding that converts to let*. That one does _not_ convert the body to one letrec, only defines following eachother.


(define a 1)

(when (even? a) (error "ERROR"))

(define b 2)


(letrec ((a ...))
  (when (even? a) (error "ERROR"))
    (letrec ((b 2))

This is not compatible with guile, but is trivial to fix!

Trivially portable to any other scheme, since it uses no fancy features except the usual module things:

On 2020-01-16 22:35, Arne Babenhauserheide wrote:
Andy Wingo <address@hidden> writes:

We are delighted to announce GNU Guile release 3.0.0, the first in the
new 3.0 stable release series.
The Guile web page is located at
That’s awesome! Thank you for your work!

Changes in 3.0.0 (since the stable 2.2 series):
** Just-in-time code generation

Guile programs now run up to 4 times faster, relative to Guile 2.2,
thanks to just-in-time (JIT) native code generation.  Notably, this
brings the performance of "eval" as written in Scheme back to the level
of "eval" written in C, as in the days of Guile 1.8.
This is awesome! I hope it finally alleviates the problems faced by Lilypond!

** Interleaved internal definitions and expressions allowed
I love that! It removes one of the early stumbling points I had with
Guile which pushed me to avoid inner defines. I only realized later how
much more readable code gets with inner defines.

Can we get this into the Scheme standard, too?

** `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'.
Guile now works around these issues by running the test portion of the
guard expressions within the original `raise' continuation, and only
unwinding once a test matches.  This is an incompatible semantic change
but we think the situation is globally much better, and we expect that
very few people will be affected by the change.
Is this semantic change a change from previous Guile or a deviation from
the Scheme standard?

Best wishes,
Unpolitisch sein
heißt politisch sein
ohne es zu merken

 - Linus Björnstam

reply via email to

[Prev in Thread] Current Thread [Next in Thread]