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.
so
(define a 1)
(when (even? a) (error "ERROR"))
(define b 2)
becomes
(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:
https://hg.sr.ht/~bjoli/guile-define/
On 2020-01-16 22:35, Arne Babenhauserheide wrote:
Andy Wingo <wi...@pobox.com> 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 http://gnu.org/software/guile/
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,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken
--
- Linus Björnstam