Re: GNU Guile 3.0.0 released

[Linus Björnstam]

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 <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 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