GNU Guile 2.9.9 Released [beta]

GNU Guile 2.9.9 Released [beta]

[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-guile@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 stack to the
cond clauses, then rewind if none match.  This is not only quite
expensive, it is also error-prone as one usually doesn't want to rewind
dynamic-wind guards in an exceptional situation.  Additionally, as
continuations bind tightly to the current thread, it makes it impossible
to migrate a subcomputation with a different thread if a `guard' is live
on the stack, as is done in Fibers.

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.

** Improve SRFI-43 vector-fill!

SRFI-43 vector-fill! now has the same performance whether an optional
range is provided or not, and is also provided in core.  As a side
effect, vector-fill! and vector_fill_x no longer work on non-vector
rank-1 arrays.  Such cases were handled incorrectly before; for example,
prior to this change:

  (define a (make-vector 10 'x))
  (define b (make-shared-array a (lambda (i) (list (* 2 i))) 5))
  (vector-fill! b 'y)

  => #1(y y y x x)

This is now an error.  Instead, use array-fill!.

** Fix compilation on 32-bit targets

A compile error introduced in 2.9.3 prevented compilation on 32-bit
targets.  This has been fixed.

** Fix a bug in closure conversion

Thanks for Stefan Israelsson Tampe for the report.

** Fix omission in R7RS support

Somewhat embarrassingly, the R7RS support added earlier in 2.9 failed to
include an implementation of `define-library'.  This oversight has been
corrected :)

** Optionally allow duplicate field names in core records

See the new #:allow-duplicate-field-names? keyword argument to
`make-record-type' in the manual, for more.  This restores a needed
feature to R6RS records.

** Fix default value of thread-local fluids

Before, `fluid-ref' on an unbound thread-local fluid was returning #f
instead of the default value of the fluid.  Thanks to Rob Browning for
the fix!


\f
Changes in alpha 2.9.x (since the stable 2.2 series):

* Notable changes

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

See "Just-In-Time Native Code" in the manual, for more information.  JIT
compilation will be enabled automatically and transparently.  To disable
JIT compilation, configure Guile with `--enable-jit=no' or
`--disable-jit'.  The default is `--enable-jit=auto', which enables the
JIT if it is available.  See `./configure --help' for more.

JIT compilation is enabled by default on x86-64, i686, ARMv7, and
AArch64 targets.

** Lower-level bytecode

Relative to the virtual machine in Guile 2.2, Guile's VM instruction set
is now more low-level.  This allows it to express more advanced
optimizations, for example type check elision or integer
devirtualization, and makes the task of JIT code generation easier.

Note that this change can mean that for a given function, the
corresponding number of instructions in Guile 3.0 may be higher than
Guile 2.2, which can lead to slowdowns when the function is interpreted.
We hope that JIT compilation more than makes up for this slight
slowdown.

** Interleaved internal definitions and expressions allowed

It used to be that internal definitions had to precede all expressions
in their bodies.  This restriction has been relaxed.  If an expression
precedes an internal definition, it is treated as if it were a
definition of an unreferenced variable.  For example, the expression
`(foo)' transforms to the equivalent of `(define _ (begin (foo) #f))',
if it precedes other definitions.

This change improves the readability of Guile programs, as it used to be
that program indentation tended to increase needlessly to allow nested
`let' and `letrec' to re-establish definition contexts after initial
expressions, for example for type-checks on procedure arguments.

** Record unification

Guile used to have a number of implementations of structured data types
in the form of "records": a core facility, SRFI-9 (records), SRFI-35
(condition types -- a form of records) and R6RS records.  These
facilities were not compatible, as they all were built in different
ways.  This had the unfortunate corollary that SRFI-35 conditions were
not compatible with R6RS conditions.  To fix this problem, we have now
added the union of functionality from all of these record types into
core records: single-inheritance subtyping, mutable and immutable
fields, and so on.  See "Records" in the manual, for full details.

R6RS records, SRFI-9 records, and the SRFI-35 and R6RS exception types
have been accordingly "rebased" on top of core records.

** Reimplementation of exceptions

Since Guile's origins 25 years ago, `throw' and `catch' have been the
primary exception-handling primitives.  However these primitives have
two problems.  One is that it's hard to handle exceptions in a
structured way using `catch'.  Few people remember what the
corresponding `key' and `args' are that an exception handler would see
in response to a call to `error', for example.  In practice, this
results in more generic catch-all exception handling than one might
like.

The other problem is that `throw', `catch', and especially
`with-throw-handler' are quite unlike what the rest of the Scheme world
uses.  R6RS and R7RS, for example, have mostly converged on
SRFI-34-style `with-exception-handler' and `raise' primitives, and
encourage the use of SRFI-35-style structured exception objects to
describe the error.  Guile's R6RS layer incorporates an adapter between
`throw'/`catch' and structured exception handling, but it didn't apply
to SRFI-34/SRFI-35, and we would have to duplicate it for R7RS.

In light of these considerations, Guile has now changed to make
`with-exception-handler' and `raise-exception' its primitives for
exception handling and defined a hierarchy of R6RS-style exception types
in its core.  SRFI-34/35, R6RS, and the exception-handling components of
SRFI-18 (threads) have been re-implemented in terms of this core
functionality.  There is also a a compatibility layer that makes it so
that exceptions originating in `throw' can be handled by
`with-exception-hander', and vice-versa for `raise-exception' and
`catch'.

Generally speaking, users will see no difference.  The one significant
difference is that users of SRFI-34 will see more exceptions flowing
through their `with-exception-handler'/`guard' forms, because whereas
before they would only see exceptions thrown by SRFI-34, now they will
see exceptions thrown by R6RS, R7RS, or indeed `throw'.

Guile's situation is transitional.  Most exceptions are still signalled
via `throw'.  These will probably migrate over time to
`raise-exception', while preserving compatibility of course.

See "Exceptions" in the manual, for full details on the new API.

** Optimization of top-level bindings within a compilation unit

At optimization level 2 and above, Guile's compiler is now allowed to
inline top-level definitions within a compilation unit.  See
"Declarative Modules" in the manual, for full details.  This change can
improve the performance of programs with many small top-level
definitions by quite a bit!

At optimization level 3 and above, Guile will assume that any top-level
binding in a declarative compilation unit that isn't exported from a
module can be completely inlined into its uses.  (Prior to this change,
-O3 was the same as -O2.)  Note that with this new
`seal-private-bindings' pass, private declarative bindings are no longer
available for access from the first-class module reflection API.  The
optimizations afforded by this pass can be useful when you need a speed
boost, but having them enabled at optimization level 3 means they are
not on by default, as they change Guile's behavior in ways that users
might not expect.

** By default, GOOPS classes are not redefinable

It used to be that all GOOPS classes were redefinable, at least in
theory.  This facility was supported by an indirection in all "struct"
instances, even though only a subset of structs would need redefinition.
We wanted to remove this indirection, in order to speed up Guile
records, allow immutable Guile records to eventually be described by
classes, and allow for some optimizations in core GOOPS classes that
shouldn't be redefined anyway.

Thus in GOOPS now there are classes that are redefinable and classes
that aren't.  By default, classes created with GOOPS are not
redefinable.  To make a class redefinable, it should be an instance of
`<redefinable-class>'.  See "Redefining a Class" in the manual for more
information.

** Define top-level bindings for aux syntax: `else', `=>', `...', `_'

These auxiliary syntax definitions are specified to be defined in the
R6RS and the R7RS.  They were previously unbound, even in the R6RS
modules.  This change is not anticipated to cause any incompatibility
with existing Guile code, and improves things for R6RS and R7RS users.

** Conventional gettext alias is now `G_'

Related to the last point, since the "Fix literal matching for
module-bound literals" change in the 2.2 series, it was no longer
possible to use the conventional `_' binding as an alias for `gettext',
because a local `_' definition would prevent `_' from being recognized
as auxiliary syntax for `match', `syntax-rules', and similar.  The new
recommended conventional alias for `gettext' is `G_'.

** Add --r6rs command-line option

The new `install-r6rs!' procedure adapts Guile's defaults to be more
R6RS-compatible.  This procedure is called if the user passes `--r6rs'
as a command-line argument.  See "R6RS Incompatibilities" in the manual,
for full details.

** Add support for R7RS

Thanks to Göran Weinholt and OKUMURA Yuki, Guile now implements the R7RS
modules.  As the R7RS library syntax is a subset of R6RS, to use R7RS
you just `(import (scheme base))' and off you go.  As with R6RS also,
there are some small lexical incompatibilities regarding hex escapes;
see "R6RS Support" in the manual, for full details.

Also as with R6RS, there is an `install-r7rs!' procedure and a `--r7rs'
command-line option.

** Add #:re-export-and-replace argument to `define-module'

This new keyword specifies a set of bindings to re-export, but also
marks them as intended to replace core bindings.  See "Creating Guile
Modules" in the manual, for full details.

Note to make this change, we had to change the way replacement flags are
stored, to being associated with modules instead of individual variable
objects.  This means that users who #:re-export an imported binding that
was already marked as #:replace by another module will now see warnings,
as they need to use #:re-export-and-replace instead.

** `iota' in core and SRFI-1 `iota' are the same

Previously, `iota' in core would not accept start and step arguments and
would return an empty list for negative count. Now there is only one
`iota' function with the extended semantics of SRFI-1.  Note that as an
incompatible change, core `iota' no longer accepts a negative count.

* New deprecations

** scm_t_uint8, etc deprecated in favor of C99 stdint.h

It used to be that Guile defined its own `scm_t_uint8' because C99
`uint8_t' wasn't widely enough available.  Now Guile finally made the
change to use C99 types, both internally and in Guile's public headers.

Note that this also applies to SCM_T_UINT8_MAX, SCM_T_INT8_MIN, for intN
and uintN for N in 8, 16, 32, and 64.  Guile also now uses ptrdiff_t
instead of scm_t_ptrdiff, and similarly for intmax_t, uintmax_t,
intptr_t, and uintptr_t.

** The two-argument form of `record-constructor'

Calling `record-constructor' with two arguments (the record type and a
list of field names) is deprecated.  Instead, call with just one
argument, and provide a wrapper around that constructor if needed.

* Incompatible changes

** All deprecated code removed

All code deprecated in Guile 2.2 has been removed.  See older NEWS, and
check that your programs can compile without linker warnings and run
without runtime warnings.  See "Deprecation" in the manual.

In particular, the function `scm_generalized_vector_get_handle' which
was deprecated in 2.0.9 but remained in 2.2, has now finally been
removed. As a replacement, use `scm_array_get_handle' to get a handle
and `scm_array_handle_rank' to check the rank.

** Remove "self" field from vtables and "redefined" field from classes

These fields were used as part of the machinery for class redefinition
and is no longer needed.

** VM hook manipulation simplified

The low-level mechanism to instrument a running virtual machine for
debugging and tracing has been simplified.  See "VM Hooks" in the
manual, for more.

* Changes to the distribution

** New effective version

The "effective version" of Guile is now 3.0, which allows parallel
installation with other effective versions (for example, the older Guile
2.2).  See "Parallel Installations" in the manual for full details.
Notably, the `pkg-config' file is now `guile-3.0', and there are new
`guile-3' and `guile-3.0' features for `cond-expand'.

Re: GNU Guile 2.9.9 Released [beta]

[Andy Wingo]

On Mon 13 Jan 2020 09:39, Andy Wingo <wingo@pobox.com> 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 :)

Re: GNU Guile 2.9.9 Released [beta]

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 1527 bytes --]

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/~cowan        cowan@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

[-- Attachment #2: Type: text/html, Size: 1905 bytes --]

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

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 842 bytes --]

bug#39118: Segfault while building on 64-bit Cygwin

[Ludovic Courtès]

Hi John,

John Cowan <cowan@ccil.org> skribis:

> 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

Could you try building 3.0.0 with JIT enabled and grab a backtrace?

Thanks in advance!

Ludo’.

Re: Segfault while building on 64-bit Cygwin

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 378 bytes --]

Yes, gladly, but I don't know how to get one in this context.  Do I need to
add some flags to the Makefile, and if so, where?  (It's a twisty maze of
passages, all different.) . Note that this *is* a build with JIT enabled;
when I disable it using the env variable, there are no errors and 3.0.0
works fine.

Also, it may take some time, as I have to rebuild my Windows system.

[-- Attachment #2: Type: text/html, Size: 466 bytes --]

bug#39118: Segfault while building on 64-bit Cygwin

[Mike Gran via Bug reports for GUILE, GNU's Ubiquitous Extension Language]

On Mon, Jan 20, 2020 at 11:38:35AM -0500, John Cowan wrote:
> Yes, gladly, but I don't know how to get one in this context.  Do I need to
> add some flags to the Makefile, and if so, where?  (It's a twisty maze of
> passages, all different.) . Note that this *is* a build with JIT enabled;
> when I disable it using the env variable, there are no errors and 3.0.0
> works fine.
> 
> Also, it may take some time, as I have to rebuild my Windows system.

I also tried building Guile 3.0.0 on Cygwin 3.1.x.  The failure comes from
trying to parse compiled .go files.

The last time that I had this sort of problem, it was because the
O_BINARY flag was dropped or missing when writing .go files, leading
to CR+LF characters in the compiled files.  And I diagnosed it by
byte-comparing Linux-compiled .go files with Cygwin-compiled .go
files, and by looking for CR+LF combinations in the compiled .go
files.

I don't know if that is what is happening here, but, I'll check that
next time I have a chance.

Thanks,
Michael

Re: Segfault while building on 64-bit Cygwin

[Andy Wingo]

On Mon 20 Jan 2020 18:22, Mike Gran <spk121@yahoo.com> writes:

> On Mon, Jan 20, 2020 at 11:38:35AM -0500, John Cowan wrote:
>> Yes, gladly, but I don't know how to get one in this context.  Do I need to
>> add some flags to the Makefile, and if so, where?  (It's a twisty maze of
>> passages, all different.) . Note that this *is* a build with JIT enabled;
>> when I disable it using the env variable, there are no errors and 3.0.0
>> works fine.
>> 
>> Also, it may take some time, as I have to rebuild my Windows system.
>
> I also tried building Guile 3.0.0 on Cygwin 3.1.x.  The failure comes from
> trying to parse compiled .go files.
>
> The last time that I had this sort of problem, it was because the
> O_BINARY flag was dropped or missing when writing .go files, leading
> to CR+LF characters in the compiled files.  And I diagnosed it by
> byte-comparing Linux-compiled .go files with Cygwin-compiled .go
> files, and by looking for CR+LF combinations in the compiled .go
> files.
>
> I don't know if that is what is happening here, but, I'll check that
> next time I have a chance.

Given that John said that compilation went fine with
GUILE_JIT_THRESHOLD=-1, I think perhaps this problem may have been fixed
in the past.  My suspicions are that this issue is an ABI issue with
lightening that could perhaps be reproduced by:

  git co https://gitlab.com/wingo/lightening
  cd lightening
  make -C tests test-native

Of course any additional confirmation is useful and welcome!

Cheers,

Andy

Re: Segfault while building on 64-bit Cygwin

[Charles Stanhope]

On 2/6/20, Andy Wingo <wingo@pobox.com> wrote:

> Given that John said that compilation went fine with
> GUILE_JIT_THRESHOLD=-1, I think perhaps this problem may have been fixed
> in the past.  My suspicions are that this issue is an ABI issue with
> lightening that could perhaps be reproduced by:
>
>   git co https://gitlab.com/wingo/lightening
>   cd lightening
>   make -C tests test-native
>
> Of course any additional confirmation is useful and welcome!

I haven't been able to get guile to compile under Cygwin (just a
compilation error I haven't had time to track down), but I was able to
quickly try the above. I get:

Testing: test-native-call_10
call_10.c:9: assertion failed: e == 4
/bin/sh: line 1:  7063 Aborted                 (core dumped) ./$test
make: *** [Makefile:31: test-native] Error 134

Despite what it says about a core dump, I find no such thing. Just a
file with the same name as the executable suffixed with ".stackdump".
(I did attempt to configure the Cygwin dumper before running the
tests.) Unless somebody suggests otherwise, I think the error message
is more useful.

--
Charles

Re: Segfault while building on 64-bit Cygwin

[Charles Stanhope]

[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]

On 2/6/20, Charles Stanhope <charles@stanho.pe> wrote:
> On 2/6/20, Andy Wingo <wingo@pobox.com> wrote:
>
>> Given that John said that compilation went fine with
>> GUILE_JIT_THRESHOLD=-1, I think perhaps this problem may have been fixed
>> in the past.  My suspicions are that this issue is an ABI issue with
>> lightening that could perhaps be reproduced by:
>>
>>   git co https://gitlab.com/wingo/lightening
>>   cd lightening
>>   make -C tests test-native
>>
>> Of course any additional confirmation is useful and welcome!
>
> I haven't been able to get guile to compile under Cygwin (just a
> compilation error I haven't had time to track down), but I was able to
> quickly try the above. I get:
>
> Testing: test-native-call_10
> call_10.c:9: assertion failed: e == 4
> /bin/sh: line 1:  7063 Aborted                 (core dumped) ./$test
> make: *** [Makefile:31: test-native] Error 134
>

Andy, I don't know if you'd want to continue this here or on
lightening's gitlab page, but I looked into this a little bit a few
minutes here and there this past weeek. The x86 "fast-call" calling
convention used on Windows x64[0] and shared by Cygwin[1] requires
that the caller reserve 32 bytes of memory on the stack for the callee
to spill the register parameters (even if the callee takes fewer than
four parameters). I think lightening is currently missing that for the
x64 case for Cygwin.

To test the idea, I made a small modification (patch attached) that is
*not* intended as a solution as it doesn't work for the general case,
but it does allow the tests to pass on Cygwin 64.

[0] https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=vs-2019
[1] https://cygwin.com/cygwin-ug-net/programming.html#gcc-64

--
Charles

[-- Attachment #2: x86-fastcall-stack-reservation.patch --]
[-- Type: text/x-patch, Size: 642 bytes --]

diff --git a/lightening/x86.c b/lightening/x86.c
index 965191a..91b3a94 100644
--- a/lightening/x86.c
+++ b/lightening/x86.c
@@ -338,11 +338,13 @@ next_abi_arg(struct abi_arg_iterator *iter, jit_operand_t *arg)
   if (is_gpr_arg(abi) && iter->gpr_idx < abi_gpr_arg_count) {
     *arg = jit_operand_gpr (abi, abi_gpr_args[iter->gpr_idx++]);
 #ifdef __CYGWIN__
+    iter->stack_size += 8;
     iter->fpr_idx++;
 #endif
   } else if (is_fpr_arg(abi) && iter->fpr_idx < abi_fpr_arg_count) {
     *arg = jit_operand_fpr (abi, abi_fpr_args[iter->fpr_idx++]);
 #ifdef __CYGWIN__
+    iter->stack_size += 8;
     iter->gpr_idx++;
 #endif
   } else {

Re: Segfault while building on 64-bit Cygwin

[Marco Atzeri]

Am 14.02.2020 um 18:46 schrieb Charles Stanhope:
> On 2/6/20, Charles Stanhope <charles@stanho.pe> wrote:
>> On 2/6/20, Andy Wingo <wingo@pobox.com> wrote:
>>
>>> Given that John said that compilation went fine with
>>> GUILE_JIT_THRESHOLD=-1, I think perhaps this problem may have been fixed
>>> in the past.  My suspicions are that this issue is an ABI issue with
>>> lightening that could perhaps be reproduced by:
>>>
>>>    git co https://gitlab.com/wingo/lightening
>>>    cd lightening
>>>    make -C tests test-native
>>>
>>> Of course any additional confirmation is useful and welcome!
>>
>> I haven't been able to get guile to compile under Cygwin (just a
>> compilation error I haven't had time to track down), but I was able to
>> quickly try the above. I get:
>>
>> Testing: test-native-call_10
>> call_10.c:9: assertion failed: e == 4
>> /bin/sh: line 1:  7063 Aborted                 (core dumped) ./$test
>> make: *** [Makefile:31: test-native] Error 134
>>
> 
> Andy, I don't know if you'd want to continue this here or on
> lightening's gitlab page, but I looked into this a little bit a few
> minutes here and there this past weeek. The x86 "fast-call" calling
> convention used on Windows x64[0] and shared by Cygwin[1] requires
> that the caller reserve 32 bytes of memory on the stack for the callee
> to spill the register parameters (even if the callee takes fewer than
> four parameters). I think lightening is currently missing that for the
> x64 case for Cygwin.
> 
> To test the idea, I made a small modification (patch attached) that is
> *not* intended as a solution as it doesn't work for the general case,
> but it does allow the tests to pass on Cygwin 64.
> 
> [0] https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=vs-2019
> [1] https://cygwin.com/cygwin-ug-net/programming.html#gcc-64
> 
> --
> Charles
> 

as guile 3.0 builds fine on Cygwin i686
but segfault immediately on bootstrap for x86_64
I bet you are right on the root cause

Marco

Re: Segfault while building on 64-bit Cygwin

[Mike Gran]

On Fri, Feb 14, 2020 at 09:46:04AM -0800, Charles Stanhope wrote:
> Andy, I don't know if you'd want to continue this here or on
> lightening's gitlab page, but I looked into this a little bit a few
> minutes here and there this past weeek. The x86 "fast-call" calling
> convention used on Windows x64[0] and shared by Cygwin[1] requires
> that the caller reserve 32 bytes of memory on the stack for the callee
> to spill the register parameters (even if the callee takes fewer than
> four parameters). I think lightening is currently missing that for the
> x64 case for Cygwin.
> 
> To test the idea, I made a small modification (patch attached) that is
> *not* intended as a solution as it doesn't work for the general case,
> but it does allow the tests to pass on Cygwin 64.

I can confirm that Charles's patch, plus another one line patch
to define CPU_SETSIZE, is enough to get Guile 3.0.x to build and run
on my box.  All tests pass except strptime in French, and the absence
of crypt.  This is a 64-bit build.

-Mike Gran

Re: Segfault while building on 64-bit Cygwin

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]

Excellent, and thank you all!  I've been WIndowsless for a few weeks, but
that should change again soon.

On Sun, Feb 16, 2020 at 6:23 PM Mike Gran <spk121@yahoo.com> wrote:

> On Fri, Feb 14, 2020 at 09:46:04AM -0800, Charles Stanhope wrote:
> > Andy, I don't know if you'd want to continue this here or on
> > lightening's gitlab page, but I looked into this a little bit a few
> > minutes here and there this past weeek. The x86 "fast-call" calling
> > convention used on Windows x64[0] and shared by Cygwin[1] requires
> > that the caller reserve 32 bytes of memory on the stack for the callee
> > to spill the register parameters (even if the callee takes fewer than
> > four parameters). I think lightening is currently missing that for the
> > x64 case for Cygwin.
> >
> > To test the idea, I made a small modification (patch attached) that is
> > *not* intended as a solution as it doesn't work for the general case,
> > but it does allow the tests to pass on Cygwin 64.
>
> I can confirm that Charles's patch, plus another one line patch
> to define CPU_SETSIZE, is enough to get Guile 3.0.x to build and run
> on my box.  All tests pass except strptime in French, and the absence
> of crypt.  This is a 64-bit build.
>
> -Mike Gran
>

[-- Attachment #2: Type: text/html, Size: 1654 bytes --]

Re: Segfault while building on 64-bit Cygwin

[Charles Stanhope]

On 2/16/20, Mike Gran <spk121@yahoo.com> wrote:
> On Fri, Feb 14, 2020 at 09:46:04AM -0800, Charles Stanhope wrote:
>> Andy, I don't know if you'd want to continue this here or on
>> lightening's gitlab page, but I looked into this a little bit a few
>> minutes here and there this past weeek. The x86 "fast-call" calling
>> convention used on Windows x64[0] and shared by Cygwin[1] requires
>> that the caller reserve 32 bytes of memory on the stack for the callee
>> to spill the register parameters (even if the callee takes fewer than
>> four parameters). I think lightening is currently missing that for the
>> x64 case for Cygwin.
>>
>> To test the idea, I made a small modification (patch attached) that is
>> *not* intended as a solution as it doesn't work for the general case,
>> but it does allow the tests to pass on Cygwin 64.
>
> I can confirm that Charles's patch, plus another one line patch
> to define CPU_SETSIZE, is enough to get Guile 3.0.x to build and run
> on my box.  All tests pass except strptime in French, and the absence
> of crypt.  This is a 64-bit build.

Mike, thanks for going further with the Guile build. The CPU_SETSIZE
issue was what was hanging me up from compiling before Andy's comment
got me to look at lightening. I assumed I had some configuration,
package, or compiler issue. Good to know there's a simple fix.

Just a further warning to anyone watching, that patch I posted is a
real hack job just to test my theory of the cause of the segfault. I
would expect it to fail when you have fewer than four arguments in a
JITed function call. I wouldn't try doing much else with that Guile
build besides run the tests. :)

--
Charles

Re: Segfault while building on 64-bit Cygwin

[Charles Stanhope]

[-- Attachment #1: Type: text/plain, Size: 1622 bytes --]

On 2/16/20, Charles Stanhope <charles@stanho.pe> wrote:
> On 2/16/20, Mike Gran <spk121@yahoo.com> wrote:
>>
>> I can confirm that Charles's patch, plus another one line patch
>> to define CPU_SETSIZE, is enough to get Guile 3.0.x to build and run
>> on my box.  All tests pass except strptime in French, and the absence
>> of crypt.  This is a 64-bit build.
>
> Mike, thanks for going further with the Guile build. The CPU_SETSIZE
> issue was what was hanging me up from compiling before Andy's comment
> got me to look at lightening. I assumed I had some configuration,
> package, or compiler issue. Good to know there's a simple fix.
>
> Just a further warning to anyone watching, that patch I posted is a
> real hack job just to test my theory of the cause of the segfault. I
> would expect it to fail when you have fewer than four arguments in a
> JITed function call. I wouldn't try doing much else with that Guile
> build besides run the tests. :)

I had a little bit more time to look into the lightening
implementation last night. I've attached a patch that is less horrible
and more correct than my previous one. It reserves the stack space
regardless of the number of parameters and appears to work. But I'm
new to the lightening code base, so I'm not convinced it is the
correct solution. It's just the solution I was left with after my time
ran out. I wanted to post this patch as a replacement to the prior one
in case people did want to do more testing with Guile 3.0 on Cygwin
x64.

With that, I will let more experienced people come up with the
appropriate solution. Happy hacking, everybody!

--
Charles

[-- Attachment #2: x86-fastcall-stack-reservation-2.patch --]
[-- Type: text/x-patch, Size: 443 bytes --]

diff --git a/lightening/x86.c b/lightening/x86.c
index 965191a..bdd26e1 100644
--- a/lightening/x86.c
+++ b/lightening/x86.c
@@ -328,6 +328,10 @@ reset_abi_arg_iterator(struct abi_arg_iterator *iter, size_t argc,
   memset(iter, 0, sizeof *iter);
   iter->argc = argc;
   iter->args = args;
+#if __CYGWIN__ && __X64
+  // Reserve slots on the stack for 4 register parameters (8 bytes each).
+  iter->stack_size = 32;
+#endif
 }
 
 static void

Re: Segfault while building on 64-bit Cygwin

[Andy Wingo]

Aah, you all are amazing -- thank you!!  Applied and merged.

Cheers,

Andy

On Mon 17 Feb 2020 20:27, Charles Stanhope <charles@stanho.pe> writes:

> On 2/16/20, Charles Stanhope <charles@stanho.pe> wrote:
>> On 2/16/20, Mike Gran <spk121@yahoo.com> wrote:
>>>
>>> I can confirm that Charles's patch, plus another one line patch
>>> to define CPU_SETSIZE, is enough to get Guile 3.0.x to build and run
>>> on my box.  All tests pass except strptime in French, and the absence
>>> of crypt.  This is a 64-bit build.
>>
>> Mike, thanks for going further with the Guile build. The CPU_SETSIZE
>> issue was what was hanging me up from compiling before Andy's comment
>> got me to look at lightening. I assumed I had some configuration,
>> package, or compiler issue. Good to know there's a simple fix.
>>
>> Just a further warning to anyone watching, that patch I posted is a
>> real hack job just to test my theory of the cause of the segfault. I
>> would expect it to fail when you have fewer than four arguments in a
>> JITed function call. I wouldn't try doing much else with that Guile
>> build besides run the tests. :)
>
> I had a little bit more time to look into the lightening
> implementation last night. I've attached a patch that is less horrible
> and more correct than my previous one. It reserves the stack space
> regardless of the number of parameters and appears to work. But I'm
> new to the lightening code base, so I'm not convinced it is the
> correct solution. It's just the solution I was left with after my time
> ran out. I wanted to post this patch as a replacement to the prior one
> in case people did want to do more testing with Guile 3.0 on Cygwin
> x64.
>
> With that, I will let more experienced people come up with the
> appropriate solution. Happy hacking, everybody!
>
> --
> Charles
>
> diff --git a/lightening/x86.c b/lightening/x86.c
> index 965191a..bdd26e1 100644
> --- a/lightening/x86.c
> +++ b/lightening/x86.c
> @@ -328,6 +328,10 @@ reset_abi_arg_iterator(struct abi_arg_iterator *iter, size_t argc,
>    memset(iter, 0, sizeof *iter);
>    iter->argc = argc;
>    iter->args = args;
> +#if __CYGWIN__ && __X64
> +  // Reserve slots on the stack for 4 register parameters (8 bytes each).
> +  iter->stack_size = 32;
> +#endif
>  }
>  
>  static void

Re: Segfault while building on 64-bit Cygwin

[Ludovic Courtès]

Hello,

John Cowan <cowan@ccil.org> skribis:

> Yes, gladly, but I don't know how to get one in this context.

You would unpack, configure, and build like you did before (with JIT
enabled, so as to reproduce the crash), but before that you’d run
“ulimit -c unlimited” in that shell to make sure there’s a core dumped
when it crashes.

Once it has crashed, locate the ‘core’ file (or ‘core.*’), and run, say:

  gdb libguile/.libs/guile bootstrap/core

Then from the GDB prompt:

  thread apply all bt

TIA,
Ludo’.

Re: bug#39118: Segfault while building on 64-bit Cygwin

[szgyg]

On Tue, Jan 21, 2020 at 10:01:58AM +0100, Ludovic Courtès wrote:
> but before that you’d run
> “ulimit -c unlimited” in that shell to make sure there’s a core dumped
> when it crashes.

This won't work on cygwin. If you want a core dump, you should use the
dumper tool, as described here
https://cygwin.com/cygwin-ug-net/dumper.html
Or you can set error_start to gdb to get an interactive gdb session on error.

s

Re: bug#39118: Segfault while building on 64-bit Cygwin

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

I'm no longer talking about Cygwin (which builds fine without JIT).  I'm
now talking about MacOS Catalina, which needs a core dump to debug, but on
which nobody seems to know how to enable core dumps.

On Tue, Jan 21, 2020 at 1:41 PM szgyg <szgyg@ludens.elte.hu> wrote:

> On Tue, Jan 21, 2020 at 10:01:58AM +0100, Ludovic Courtès wrote:
> > but before that you’d run
> > “ulimit -c unlimited” in that shell to make sure there’s a core dumped
> > when it crashes.
>
> This won't work on cygwin. If you want a core dump, you should use the
> dumper tool, as described here
> https://cygwin.com/cygwin-ug-net/dumper.html
> Or you can set error_start to gdb to get an interactive gdb session on
> error.
>
> s
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1161 bytes --]

Re: Segfault while building on 64-bit Cygwin

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

Thanks.  Unfortunately, the standard recipe for making core dumps on Mac
(put "limit core unlimited" into /etc/launchd.conf and reboot, make sure
/cores is writable, set ulimit -c unlimited) seem to actually enable them
on MacOS Catalina (10.15.2).  I have tested with SIGQUIT and SIGSEGV on
running processes and no dumps appear in /cores.

On Tue, Jan 21, 2020 at 4:02 AM Ludovic Courtès <ludo@gnu.org> wrote:

> Hello,
>
> John Cowan <cowan@ccil.org> skribis:
>
> > Yes, gladly, but I don't know how to get one in this context.
>
> You would unpack, configure, and build like you did before (with JIT
> enabled, so as to reproduce the crash), but before that you’d run
> “ulimit -c unlimited” in that shell to make sure there’s a core dumped
> when it crashes.
>
> Once it has crashed, locate the ‘core’ file (or ‘core.*’), and run, say:
>
>   gdb libguile/.libs/guile bootstrap/core
>
> Then from the GDB prompt:
>
>   thread apply all bt
>
> TIA,
> Ludo’.
>

[-- Attachment #2: Type: text/html, Size: 1407 bytes --]

Re: Segfault while building on 64-bit Cygwin

[Ludovic Courtès]

Hi,

John Cowan <cowan@ccil.org> skribis:

> Thanks.  Unfortunately, the standard recipe for making core dumps on Mac

This bug report is about Cygwin, not macOS, right?  :-)

Ludo’.

Re: Segfault while building on 64-bit Cygwin

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 1697 bytes --]

Both Cygwin and MacOS crash in pretty much the same way.  By disabling the
JIT, I was able to get the Cygwin build to run to completion.  On MacOS
with --disable-jit, however, I am now getting an entirely new failure:

  CC       readline.lo
readline.c:432:7: warning: implicitly declaring library function 'strncmp'
with type 'int (const char *, const char *,
      unsigned long)' [-Wimplicit-function-declaration]
  if (strncmp (rl_get_keymap_name (rl_get_keymap ()), "vi", 2))
      ^
readline.c:432:7: note: include the header <string.h> or explicitly provide
a declaration for 'strncmp'
readline.c:432:16: warning: implicit declaration of function
'rl_get_keymap_name' is invalid in C99
      [-Wimplicit-function-declaration]
  if (strncmp (rl_get_keymap_name (rl_get_keymap ()), "vi", 2))
               ^
readline.c:432:16: warning: incompatible integer to pointer conversion
passing 'int' to parameter of type 'const char *'
      [-Wint-conversion]
  if (strncmp (rl_get_keymap_name (rl_get_keymap ()), "vi", 2))
               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3 warnings generated.
  CCLD     guile-readline.la
Undefined symbols for architecture x86_64:
  "_rl_get_keymap_name", referenced from:
      _scm_init_readline in readline.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)

On Thu, Jan 23, 2020 at 3:35 PM Ludovic Courtès <ludo@gnu.org> wrote:

> Hi,
>
> John Cowan <cowan@ccil.org> skribis:
>
> > Thanks.  Unfortunately, the standard recipe for making core dumps on Mac
>
> This bug report is about Cygwin, not macOS, right?  :-)
>
> Ludo’.
>

[-- Attachment #2: Type: text/html, Size: 2283 bytes --]

Re: Segfault while building on 64-bit Cygwin

[Ludovic Courtès]

John Cowan <cowan@ccil.org> skribis:

> Both Cygwin and MacOS crash in pretty much the same way.  By disabling the
> JIT, I was able to get the Cygwin build to run to completion.

That I understand.  However, I was asking for the backtrace of the crash
on Cygwin when JIT is enabled.  Could you grab it?

Thanks in advance,
Ludo’.

Re: Segfault while building on 64-bit Cygwin

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]

On Sat, Jan 25, 2020 at 8:51 AM Ludovic Courtès <ludo@gnu.org> wrote:


> That I understand.  However, I was asking for the backtrace of the crash
> on Cygwin when JIT is enabled.  Could you grab it?
>

1. The wisdom of the Internet has not been able to figure out how to
generate a core dump on MacOS 10.15.2 (Catalina).  The usual set of
enabling steps can be performed without error, but still no core dump.

2. Until today I believed that there was no way to generate a Cygwin core
dump.  I know now that there is, but I may not be able to test it until
Monday.  I'll let you know, and hopefully that will provide insight into
the MacOS problem as well.

3.  I will try to work further on the MacOS libffi problem (which surfaces
when you do --disable-jit to bypass the above problem) to convince MacOS to
use GNU libffi rather than the native one.  It probably has to do with
pkg-config, which I barely understand.

"All problems are config problems."



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
We are lost, lost.  No name, no business, no Precious, nothing.  Only empty.
Only hungry: yes, we are hungry.  A few little fishes, nassty bony little
fishes, for a poor creature, and they say death.  So wise they are; so just,
so very just.  --Gollum

[-- Attachment #2: Type: text/html, Size: 1879 bytes --]

bug#39118: Segfault while building on 64-bit Cygwin

[John Cowan]

[-- Attachment #1.1: Type: text/plain, Size: 2195 bytes --]

Aaaand... Cygwin doesn't do core dumps. Under the skin it's WIndows, after
all.  This is what I get when I specify ulimit -c unlimited and rebuild:

Exception: STATUS_ACCESS_VIOLATION at rip=0055A8B1B25
rax=0000000000000000 rbx=FFFFFFFFFFFFFF90 rcx=FFFFFFFFFFFFFF90
rdx=000000000034964A rsi=000007000084ECC0 rdi=FFFFFFFFFFFFFF90
r8 =000007000084ECC0 r9 =0000000000000002 r10=0000000100000000
r11=000000055A86B190 r12=0000000000000002 r13=000000055A931EA0
r14=000006FFFFFEF840 r15=0000000000000000
rbp=000000000034964A rsp=00000000FFFFBDA0
program=C:\Users\rr828893\Downloads\guile-3.0.0\libguile\.libs\guile.exe,
pid 62833, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B

I can't imagine what you can make of that.

On Sat, Jan 25, 2020 at 10:54 AM John Cowan <cowan@ccil.org> wrote:

>
>
> On Sat, Jan 25, 2020 at 8:51 AM Ludovic Courtès <ludo@gnu.org> wrote:
>
>
>> That I understand.  However, I was asking for the backtrace of the crash
>> on Cygwin when JIT is enabled.  Could you grab it?
>>
>
> 1. The wisdom of the Internet has not been able to figure out how to
> generate a core dump on MacOS 10.15.2 (Catalina).  The usual set of
> enabling steps can be performed without error, but still no core dump.
>
> 2. Until today I believed that there was no way to generate a Cygwin core
> dump.  I know now that there is, but I may not be able to test it until
> Monday.  I'll let you know, and hopefully that will provide insight into
> the MacOS problem as well.
>
> 3.  I will try to work further on the MacOS libffi problem (which surfaces
> when you do --disable-jit to bypass the above problem) to convince MacOS to
> use GNU libffi rather than the native one.  It probably has to do with
> pkg-config, which I barely understand.
>
> "All problems are config problems."
>
>
>
> John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
> We are lost, lost.  No name, no business, no Precious, nothing.  Only
> empty.
> Only hungry: yes, we are hungry.  A few little fishes, nassty bony little
> fishes, for a poor creature, and they say death.  So wise they are; so
> just,
> so very just.  --Gollum
>

[-- Attachment #1.2: Type: text/html, Size: 3104 bytes --]

[-- Attachment #2: guile.exe.stackdump --]
[-- Type: application/octet-stream, Size: 544 bytes --]

Exception: STATUS_ACCESS_VIOLATION at rip=0055A8B1B25
rax=0000000000000000 rbx=FFFFFFFFFFFFFF90 rcx=FFFFFFFFFFFFFF90
rdx=000000000034964A rsi=000007000084ECC0 rdi=FFFFFFFFFFFFFF90
r8 =000007000084ECC0 r9 =0000000000000002 r10=0000000100000000
r11=000000055A86B190 r12=0000000000000002 r13=000000055A931EA0
r14=000006FFFFFEF840 r15=0000000000000000
rbp=000000000034964A rsp=00000000FFFFBDA0
program=C:\Users\rr828893\Downloads\guile-3.0.0\libguile\.libs\guile.exe, pid 62833, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B

bug#39118: Segfault while building on 64-bit Cygwin

[szgyg]

On Fri, Jan 31, 2020 at 09:23:19AM -0500, John Cowan wrote:
> Aaaand... Cygwin doesn't do core dumps. Under the skin it's WIndows, after
> all.  This is what I get when I specify ulimit -c unlimited and rebuild:
> [...]

Please see my previous mail on how to get a real core dump on cygwin
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39118#28


>> On Sat, Jan 25, 2020 at 8:51 AM Ludovic Courtès <ludo@gnu.org> wrote:
>>
>>> That I understand.  However, I was asking for the backtrace of the crash
>>> on Cygwin when JIT is enabled.  Could you grab it?

#v+
  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

Thread 1 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 7444.0x2640]
0x000000055a8b1b25 in scm_to_uint64 (val=val@entry=0xffffffffffffff90) at ../../guile-3.0.0/libguile/conv-uinteger.i.c:44
44        else if (SCM_BIGP (val))
(gdb) bt
#0  0x000000055a8b1b25 in scm_to_uint64 (val=val@entry=0xffffffffffffff90) at ../../guile-3.0.0/libguile/conv-uinteger.i.c:44
#1  0x000000055a86b1ea in scm_bytevector_copy_x (source=0x700000948620, source_start=0x34964a, target=0x700000907600, target_start=0x2, len=0xffffffffffffff90)
    at ../../guile-3.0.0/libguile/bytevectors.c:604
#2  0x00006ffffe743866 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

  BOOTSTRAP GUILEC language/tree-il.go

(gdb) bt
#0  0x000000055a8b1b25 in scm_to_uint64 (val=val@entry=0xffffffffffffff90)
    at ../../guile-3.0.0/libguile/conv-uinteger.i.c:44
#1  0x000000055a86b1ea in scm_bytevector_copy_x (source=0x70000055f160, source_start=0x34964a, target=0x700000808c90,
    target_start=0x2, len=0xffffffffffffff90) at ../../guile-3.0.0/libguile/bytevectors.c:604
#2  0x00006ffffe73f936 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

  BOOTSTRAP GUILEC language/tree-il/analyze.go

(gdb) bt
#0  0x000000055a8b1b25 in scm_to_uint64 (val=val@entry=0xffffffffffffff90)
    at ../../guile-3.0.0/libguile/conv-uinteger.i.c:44
#1  0x000000055a86b1ea in scm_bytevector_copy_x (source=0x700000645160, source_start=0x34964a, target=0x7000008012d0,
    target_start=0x2, len=0xffffffffffffff90) at ../../guile-3.0.0/libguile/bytevectors.c:604
#2  0x00006ffffe753fc6 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

^C
#v-

s

Re: bug#39118: Segfault while building on 64-bit Cygwin

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 1414 bytes --]

On Mon, Feb 3, 2020 at 5:11 PM szgyg <szgyg@ludens.elte.hu> wrote:

On Fri, Jan 31, 2020 at 09:23:19AM -0500, John Cowan wrote:
> > Aaaand... Cygwin doesn't do core dumps. Under the skin it's WIndows,
> after
> > all.  This is what I get when I specify ulimit -c unlimited and rebuild:
> > [...]
>
> Please see my previous mail on how to get a real core dump on cygwin
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39118#28


Okay, I looked at that page.  However, Cygwin's dumper requires you to know
the Windows PID of the process to dump.  Clearly it is intended for a
long-running process such as a server process, which you can force to core
dump, as if by "/bin/kill -SIGSEGV pid"; it is not suitable for a process
that gets a segmentation violation for internal reasons.  In any case, when
building, I have no idea of the pid of the process which is dumping; it
starts up and then dumps immediately.



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
The Penguin shall hunt and devour all that is crufty, gnarly and
bogacious; all code which wriggles like spaghetti, or is infested with
blighting creatures, or is bound by grave and perilous Licences shall it
capture.  And in capturing shall it replicate, and in replicating shall
it document, and in documentation shall it bring freedom, serenity and
most cool froodiness to the earth and all who code therein.  --Gospel of Tux

[-- Attachment #2: Type: text/html, Size: 2122 bytes --]

Re: bug#39118: Segfault while building on 64-bit Cygwin

[szgyg]

On Wed, Feb 05, 2020 at 04:11:04PM -0500, John Cowan wrote:
> On Mon, Feb 3, 2020 at 5:11 PM szgyg <szgyg@ludens.elte.hu> wrote:
> 
> On Fri, Jan 31, 2020 at 09:23:19AM -0500, John Cowan wrote:
> > > Aaaand... Cygwin doesn't do core dumps. Under the skin it's WIndows,
> > after
> > > all.  This is what I get when I specify ulimit -c unlimited and rebuild:
> > > [...]
> >
> > Please see my previous mail on how to get a real core dump on cygwin
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39118#28
> 
> 
> Okay, I looked at that page.  However, Cygwin's dumper requires you to know
> the Windows PID of the process to dump.  Clearly it is intended for a
> long-running process such as a server process, which you can force to core
> dump, as if by "/bin/kill -SIGSEGV pid"; it is not suitable for a process
> that gets a segmentation violation for internal reasons.  In any case, when
> building, I have no idea of the pid of the process which is dumping; it
> starts up and then dumps immediately.


| One common way to use dumper is to plug it into cygwin's Just-In-Time
| debugging facility by adding
| error_start=x:\path\to\dumper.exe
| to the CYGWIN environment variable. Please note that x:\path\to\dumper.exe
| is Windows-style and not cygwin path. If error_start is set this way, then
| dumper will be started whenever some program encounters a fatal error.


s

Re: GNU Guile 2.9.9 Released [beta]

[Stefan Israelsson Tampe]

[-- Attachment #1: Type: text/plain, Size: 20572 bytes --]

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)

;;; (#<procedure eq? (#:optional _ _ . _)> #f)

;;; (#<procedure eqv? (#:optional _ _ . _)> #f)

;;; (#<procedure equal? (#:optional _ _ . _)> #f)

;;; (139824931374184 139824931374200)


On Mon, Jan 13, 2020 at 9:39 AM Andy Wingo <wingo@pobox.com> 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-guile@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 stack to the
> cond clauses, then rewind if none match.  This is not only quite
> expensive, it is also error-prone as one usually doesn't want to rewind
> dynamic-wind guards in an exceptional situation.  Additionally, as
> continuations bind tightly to the current thread, it makes it impossible
> to migrate a subcomputation with a different thread if a `guard' is live
> on the stack, as is done in Fibers.
>
> 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.
>
> ** Improve SRFI-43 vector-fill!
>
> SRFI-43 vector-fill! now has the same performance whether an optional
> range is provided or not, and is also provided in core.  As a side
> effect, vector-fill! and vector_fill_x no longer work on non-vector
> rank-1 arrays.  Such cases were handled incorrectly before; for example,
> prior to this change:
>
>   (define a (make-vector 10 'x))
>   (define b (make-shared-array a (lambda (i) (list (* 2 i))) 5))
>   (vector-fill! b 'y)
>
>   => #1(y y y x x)
>
> This is now an error.  Instead, use array-fill!.
>
> ** Fix compilation on 32-bit targets
>
> A compile error introduced in 2.9.3 prevented compilation on 32-bit
> targets.  This has been fixed.
>
> ** Fix a bug in closure conversion
>
> Thanks for Stefan Israelsson Tampe for the report.
>
> ** Fix omission in R7RS support
>
> Somewhat embarrassingly, the R7RS support added earlier in 2.9 failed to
> include an implementation of `define-library'.  This oversight has been
> corrected :)
>
> ** Optionally allow duplicate field names in core records
>
> See the new #:allow-duplicate-field-names? keyword argument to
> `make-record-type' in the manual, for more.  This restores a needed
> feature to R6RS records.
>
> ** Fix default value of thread-local fluids
>
> Before, `fluid-ref' on an unbound thread-local fluid was returning #f
> instead of the default value of the fluid.  Thanks to Rob Browning for
> the fix!
>
>
>
> Changes in alpha 2.9.x (since the stable 2.2 series):
>
> * Notable changes
>
> ** 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.
>
> See "Just-In-Time Native Code" in the manual, for more information.  JIT
> compilation will be enabled automatically and transparently.  To disable
> JIT compilation, configure Guile with `--enable-jit=no' or
> `--disable-jit'.  The default is `--enable-jit=auto', which enables the
> JIT if it is available.  See `./configure --help' for more.
>
> JIT compilation is enabled by default on x86-64, i686, ARMv7, and
> AArch64 targets.
>
> ** Lower-level bytecode
>
> Relative to the virtual machine in Guile 2.2, Guile's VM instruction set
> is now more low-level.  This allows it to express more advanced
> optimizations, for example type check elision or integer
> devirtualization, and makes the task of JIT code generation easier.
>
> Note that this change can mean that for a given function, the
> corresponding number of instructions in Guile 3.0 may be higher than
> Guile 2.2, which can lead to slowdowns when the function is interpreted.
> We hope that JIT compilation more than makes up for this slight
> slowdown.
>
> ** Interleaved internal definitions and expressions allowed
>
> It used to be that internal definitions had to precede all expressions
> in their bodies.  This restriction has been relaxed.  If an expression
> precedes an internal definition, it is treated as if it were a
> definition of an unreferenced variable.  For example, the expression
> `(foo)' transforms to the equivalent of `(define _ (begin (foo) #f))',
> if it precedes other definitions.
>
> This change improves the readability of Guile programs, as it used to be
> that program indentation tended to increase needlessly to allow nested
> `let' and `letrec' to re-establish definition contexts after initial
> expressions, for example for type-checks on procedure arguments.
>
> ** Record unification
>
> Guile used to have a number of implementations of structured data types
> in the form of "records": a core facility, SRFI-9 (records), SRFI-35
> (condition types -- a form of records) and R6RS records.  These
> facilities were not compatible, as they all were built in different
> ways.  This had the unfortunate corollary that SRFI-35 conditions were
> not compatible with R6RS conditions.  To fix this problem, we have now
> added the union of functionality from all of these record types into
> core records: single-inheritance subtyping, mutable and immutable
> fields, and so on.  See "Records" in the manual, for full details.
>
> R6RS records, SRFI-9 records, and the SRFI-35 and R6RS exception types
> have been accordingly "rebased" on top of core records.
>
> ** Reimplementation of exceptions
>
> Since Guile's origins 25 years ago, `throw' and `catch' have been the
> primary exception-handling primitives.  However these primitives have
> two problems.  One is that it's hard to handle exceptions in a
> structured way using `catch'.  Few people remember what the
> corresponding `key' and `args' are that an exception handler would see
> in response to a call to `error', for example.  In practice, this
> results in more generic catch-all exception handling than one might
> like.
>
> The other problem is that `throw', `catch', and especially
> `with-throw-handler' are quite unlike what the rest of the Scheme world
> uses.  R6RS and R7RS, for example, have mostly converged on
> SRFI-34-style `with-exception-handler' and `raise' primitives, and
> encourage the use of SRFI-35-style structured exception objects to
> describe the error.  Guile's R6RS layer incorporates an adapter between
> `throw'/`catch' and structured exception handling, but it didn't apply
> to SRFI-34/SRFI-35, and we would have to duplicate it for R7RS.
>
> In light of these considerations, Guile has now changed to make
> `with-exception-handler' and `raise-exception' its primitives for
> exception handling and defined a hierarchy of R6RS-style exception types
> in its core.  SRFI-34/35, R6RS, and the exception-handling components of
> SRFI-18 (threads) have been re-implemented in terms of this core
> functionality.  There is also a a compatibility layer that makes it so
> that exceptions originating in `throw' can be handled by
> `with-exception-hander', and vice-versa for `raise-exception' and
> `catch'.
>
> Generally speaking, users will see no difference.  The one significant
> difference is that users of SRFI-34 will see more exceptions flowing
> through their `with-exception-handler'/`guard' forms, because whereas
> before they would only see exceptions thrown by SRFI-34, now they will
> see exceptions thrown by R6RS, R7RS, or indeed `throw'.
>
> Guile's situation is transitional.  Most exceptions are still signalled
> via `throw'.  These will probably migrate over time to
> `raise-exception', while preserving compatibility of course.
>
> See "Exceptions" in the manual, for full details on the new API.
>
> ** Optimization of top-level bindings within a compilation unit
>
> At optimization level 2 and above, Guile's compiler is now allowed to
> inline top-level definitions within a compilation unit.  See
> "Declarative Modules" in the manual, for full details.  This change can
> improve the performance of programs with many small top-level
> definitions by quite a bit!
>
> At optimization level 3 and above, Guile will assume that any top-level
> binding in a declarative compilation unit that isn't exported from a
> module can be completely inlined into its uses.  (Prior to this change,
> -O3 was the same as -O2.)  Note that with this new
> `seal-private-bindings' pass, private declarative bindings are no longer
> available for access from the first-class module reflection API.  The
> optimizations afforded by this pass can be useful when you need a speed
> boost, but having them enabled at optimization level 3 means they are
> not on by default, as they change Guile's behavior in ways that users
> might not expect.
>
> ** By default, GOOPS classes are not redefinable
>
> It used to be that all GOOPS classes were redefinable, at least in
> theory.  This facility was supported by an indirection in all "struct"
> instances, even though only a subset of structs would need redefinition.
> We wanted to remove this indirection, in order to speed up Guile
> records, allow immutable Guile records to eventually be described by
> classes, and allow for some optimizations in core GOOPS classes that
> shouldn't be redefined anyway.
>
> Thus in GOOPS now there are classes that are redefinable and classes
> that aren't.  By default, classes created with GOOPS are not
> redefinable.  To make a class redefinable, it should be an instance of
> `<redefinable-class>'.  See "Redefining a Class" in the manual for more
> information.
>
> ** Define top-level bindings for aux syntax: `else', `=>', `...', `_'
>
> These auxiliary syntax definitions are specified to be defined in the
> R6RS and the R7RS.  They were previously unbound, even in the R6RS
> modules.  This change is not anticipated to cause any incompatibility
> with existing Guile code, and improves things for R6RS and R7RS users.
>
> ** Conventional gettext alias is now `G_'
>
> Related to the last point, since the "Fix literal matching for
> module-bound literals" change in the 2.2 series, it was no longer
> possible to use the conventional `_' binding as an alias for `gettext',
> because a local `_' definition would prevent `_' from being recognized
> as auxiliary syntax for `match', `syntax-rules', and similar.  The new
> recommended conventional alias for `gettext' is `G_'.
>
> ** Add --r6rs command-line option
>
> The new `install-r6rs!' procedure adapts Guile's defaults to be more
> R6RS-compatible.  This procedure is called if the user passes `--r6rs'
> as a command-line argument.  See "R6RS Incompatibilities" in the manual,
> for full details.
>
> ** Add support for R7RS
>
> Thanks to Göran Weinholt and OKUMURA Yuki, Guile now implements the R7RS
> modules.  As the R7RS library syntax is a subset of R6RS, to use R7RS
> you just `(import (scheme base))' and off you go.  As with R6RS also,
> there are some small lexical incompatibilities regarding hex escapes;
> see "R6RS Support" in the manual, for full details.
>
> Also as with R6RS, there is an `install-r7rs!' procedure and a `--r7rs'
> command-line option.
>
> ** Add #:re-export-and-replace argument to `define-module'
>
> This new keyword specifies a set of bindings to re-export, but also
> marks them as intended to replace core bindings.  See "Creating Guile
> Modules" in the manual, for full details.
>
> Note to make this change, we had to change the way replacement flags are
> stored, to being associated with modules instead of individual variable
> objects.  This means that users who #:re-export an imported binding that
> was already marked as #:replace by another module will now see warnings,
> as they need to use #:re-export-and-replace instead.
>
> ** `iota' in core and SRFI-1 `iota' are the same
>
> Previously, `iota' in core would not accept start and step arguments and
> would return an empty list for negative count. Now there is only one
> `iota' function with the extended semantics of SRFI-1.  Note that as an
> incompatible change, core `iota' no longer accepts a negative count.
>
> * New deprecations
>
> ** scm_t_uint8, etc deprecated in favor of C99 stdint.h
>
> It used to be that Guile defined its own `scm_t_uint8' because C99
> `uint8_t' wasn't widely enough available.  Now Guile finally made the
> change to use C99 types, both internally and in Guile's public headers.
>
> Note that this also applies to SCM_T_UINT8_MAX, SCM_T_INT8_MIN, for intN
> and uintN for N in 8, 16, 32, and 64.  Guile also now uses ptrdiff_t
> instead of scm_t_ptrdiff, and similarly for intmax_t, uintmax_t,
> intptr_t, and uintptr_t.
>
> ** The two-argument form of `record-constructor'
>
> Calling `record-constructor' with two arguments (the record type and a
> list of field names) is deprecated.  Instead, call with just one
> argument, and provide a wrapper around that constructor if needed.
>
> * Incompatible changes
>
> ** All deprecated code removed
>
> All code deprecated in Guile 2.2 has been removed.  See older NEWS, and
> check that your programs can compile without linker warnings and run
> without runtime warnings.  See "Deprecation" in the manual.
>
> In particular, the function `scm_generalized_vector_get_handle' which
> was deprecated in 2.0.9 but remained in 2.2, has now finally been
> removed. As a replacement, use `scm_array_get_handle' to get a handle
> and `scm_array_handle_rank' to check the rank.
>
> ** Remove "self" field from vtables and "redefined" field from classes
>
> These fields were used as part of the machinery for class redefinition
> and is no longer needed.
>
> ** VM hook manipulation simplified
>
> The low-level mechanism to instrument a running virtual machine for
> debugging and tracing has been simplified.  See "VM Hooks" in the
> manual, for more.
>
> * Changes to the distribution
>
> ** New effective version
>
> The "effective version" of Guile is now 3.0, which allows parallel
> installation with other effective versions (for example, the older Guile
> 2.2).  See "Parallel Installations" in the manual for full details.
> Notably, the `pkg-config' file is now `guile-3.0', and there are new
> `guile-3' and `guile-3.0' features for `cond-expand'.
>
>

[-- Attachment #2: Type: text/html, Size: 23885 bytes --]

Re: GNU Guile 2.9.9 Released [beta]

[Stefan Israelsson Tampe]

[-- Attachment #1: Type: text/plain, Size: 21201 bytes --]

I mean that this bug is for 2.9.9

On Mon, Jan 13, 2020 at 10:32 PM Stefan Israelsson Tampe <
stefan.itampe@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)
>
> ;;; (#<procedure eq? (#:optional _ _ . _)> #f)
>
> ;;; (#<procedure eqv? (#:optional _ _ . _)> #f)
>
> ;;; (#<procedure equal? (#:optional _ _ . _)> #f)
>
> ;;; (139824931374184 139824931374200)
>
>
> On Mon, Jan 13, 2020 at 9:39 AM Andy Wingo <wingo@pobox.com> 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-guile@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 stack to the
>> cond clauses, then rewind if none match.  This is not only quite
>> expensive, it is also error-prone as one usually doesn't want to rewind
>> dynamic-wind guards in an exceptional situation.  Additionally, as
>> continuations bind tightly to the current thread, it makes it impossible
>> to migrate a subcomputation with a different thread if a `guard' is live
>> on the stack, as is done in Fibers.
>>
>> 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.
>>
>> ** Improve SRFI-43 vector-fill!
>>
>> SRFI-43 vector-fill! now has the same performance whether an optional
>> range is provided or not, and is also provided in core.  As a side
>> effect, vector-fill! and vector_fill_x no longer work on non-vector
>> rank-1 arrays.  Such cases were handled incorrectly before; for example,
>> prior to this change:
>>
>>   (define a (make-vector 10 'x))
>>   (define b (make-shared-array a (lambda (i) (list (* 2 i))) 5))
>>   (vector-fill! b 'y)
>>
>>   => #1(y y y x x)
>>
>> This is now an error.  Instead, use array-fill!.
>>
>> ** Fix compilation on 32-bit targets
>>
>> A compile error introduced in 2.9.3 prevented compilation on 32-bit
>> targets.  This has been fixed.
>>
>> ** Fix a bug in closure conversion
>>
>> Thanks for Stefan Israelsson Tampe for the report.
>>
>> ** Fix omission in R7RS support
>>
>> Somewhat embarrassingly, the R7RS support added earlier in 2.9 failed to
>> include an implementation of `define-library'.  This oversight has been
>> corrected :)
>>
>> ** Optionally allow duplicate field names in core records
>>
>> See the new #:allow-duplicate-field-names? keyword argument to
>> `make-record-type' in the manual, for more.  This restores a needed
>> feature to R6RS records.
>>
>> ** Fix default value of thread-local fluids
>>
>> Before, `fluid-ref' on an unbound thread-local fluid was returning #f
>> instead of the default value of the fluid.  Thanks to Rob Browning for
>> the fix!
>>
>>
>>
>> Changes in alpha 2.9.x (since the stable 2.2 series):
>>
>> * Notable changes
>>
>> ** 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.
>>
>> See "Just-In-Time Native Code" in the manual, for more information.  JIT
>> compilation will be enabled automatically and transparently.  To disable
>> JIT compilation, configure Guile with `--enable-jit=no' or
>> `--disable-jit'.  The default is `--enable-jit=auto', which enables the
>> JIT if it is available.  See `./configure --help' for more.
>>
>> JIT compilation is enabled by default on x86-64, i686, ARMv7, and
>> AArch64 targets.
>>
>> ** Lower-level bytecode
>>
>> Relative to the virtual machine in Guile 2.2, Guile's VM instruction set
>> is now more low-level.  This allows it to express more advanced
>> optimizations, for example type check elision or integer
>> devirtualization, and makes the task of JIT code generation easier.
>>
>> Note that this change can mean that for a given function, the
>> corresponding number of instructions in Guile 3.0 may be higher than
>> Guile 2.2, which can lead to slowdowns when the function is interpreted.
>> We hope that JIT compilation more than makes up for this slight
>> slowdown.
>>
>> ** Interleaved internal definitions and expressions allowed
>>
>> It used to be that internal definitions had to precede all expressions
>> in their bodies.  This restriction has been relaxed.  If an expression
>> precedes an internal definition, it is treated as if it were a
>> definition of an unreferenced variable.  For example, the expression
>> `(foo)' transforms to the equivalent of `(define _ (begin (foo) #f))',
>> if it precedes other definitions.
>>
>> This change improves the readability of Guile programs, as it used to be
>> that program indentation tended to increase needlessly to allow nested
>> `let' and `letrec' to re-establish definition contexts after initial
>> expressions, for example for type-checks on procedure arguments.
>>
>> ** Record unification
>>
>> Guile used to have a number of implementations of structured data types
>> in the form of "records": a core facility, SRFI-9 (records), SRFI-35
>> (condition types -- a form of records) and R6RS records.  These
>> facilities were not compatible, as they all were built in different
>> ways.  This had the unfortunate corollary that SRFI-35 conditions were
>> not compatible with R6RS conditions.  To fix this problem, we have now
>> added the union of functionality from all of these record types into
>> core records: single-inheritance subtyping, mutable and immutable
>> fields, and so on.  See "Records" in the manual, for full details.
>>
>> R6RS records, SRFI-9 records, and the SRFI-35 and R6RS exception types
>> have been accordingly "rebased" on top of core records.
>>
>> ** Reimplementation of exceptions
>>
>> Since Guile's origins 25 years ago, `throw' and `catch' have been the
>> primary exception-handling primitives.  However these primitives have
>> two problems.  One is that it's hard to handle exceptions in a
>> structured way using `catch'.  Few people remember what the
>> corresponding `key' and `args' are that an exception handler would see
>> in response to a call to `error', for example.  In practice, this
>> results in more generic catch-all exception handling than one might
>> like.
>>
>> The other problem is that `throw', `catch', and especially
>> `with-throw-handler' are quite unlike what the rest of the Scheme world
>> uses.  R6RS and R7RS, for example, have mostly converged on
>> SRFI-34-style `with-exception-handler' and `raise' primitives, and
>> encourage the use of SRFI-35-style structured exception objects to
>> describe the error.  Guile's R6RS layer incorporates an adapter between
>> `throw'/`catch' and structured exception handling, but it didn't apply
>> to SRFI-34/SRFI-35, and we would have to duplicate it for R7RS.
>>
>> In light of these considerations, Guile has now changed to make
>> `with-exception-handler' and `raise-exception' its primitives for
>> exception handling and defined a hierarchy of R6RS-style exception types
>> in its core.  SRFI-34/35, R6RS, and the exception-handling components of
>> SRFI-18 (threads) have been re-implemented in terms of this core
>> functionality.  There is also a a compatibility layer that makes it so
>> that exceptions originating in `throw' can be handled by
>> `with-exception-hander', and vice-versa for `raise-exception' and
>> `catch'.
>>
>> Generally speaking, users will see no difference.  The one significant
>> difference is that users of SRFI-34 will see more exceptions flowing
>> through their `with-exception-handler'/`guard' forms, because whereas
>> before they would only see exceptions thrown by SRFI-34, now they will
>> see exceptions thrown by R6RS, R7RS, or indeed `throw'.
>>
>> Guile's situation is transitional.  Most exceptions are still signalled
>> via `throw'.  These will probably migrate over time to
>> `raise-exception', while preserving compatibility of course.
>>
>> See "Exceptions" in the manual, for full details on the new API.
>>
>> ** Optimization of top-level bindings within a compilation unit
>>
>> At optimization level 2 and above, Guile's compiler is now allowed to
>> inline top-level definitions within a compilation unit.  See
>> "Declarative Modules" in the manual, for full details.  This change can
>> improve the performance of programs with many small top-level
>> definitions by quite a bit!
>>
>> At optimization level 3 and above, Guile will assume that any top-level
>> binding in a declarative compilation unit that isn't exported from a
>> module can be completely inlined into its uses.  (Prior to this change,
>> -O3 was the same as -O2.)  Note that with this new
>> `seal-private-bindings' pass, private declarative bindings are no longer
>> available for access from the first-class module reflection API.  The
>> optimizations afforded by this pass can be useful when you need a speed
>> boost, but having them enabled at optimization level 3 means they are
>> not on by default, as they change Guile's behavior in ways that users
>> might not expect.
>>
>> ** By default, GOOPS classes are not redefinable
>>
>> It used to be that all GOOPS classes were redefinable, at least in
>> theory.  This facility was supported by an indirection in all "struct"
>> instances, even though only a subset of structs would need redefinition.
>> We wanted to remove this indirection, in order to speed up Guile
>> records, allow immutable Guile records to eventually be described by
>> classes, and allow for some optimizations in core GOOPS classes that
>> shouldn't be redefined anyway.
>>
>> Thus in GOOPS now there are classes that are redefinable and classes
>> that aren't.  By default, classes created with GOOPS are not
>> redefinable.  To make a class redefinable, it should be an instance of
>> `<redefinable-class>'.  See "Redefining a Class" in the manual for more
>> information.
>>
>> ** Define top-level bindings for aux syntax: `else', `=>', `...', `_'
>>
>> These auxiliary syntax definitions are specified to be defined in the
>> R6RS and the R7RS.  They were previously unbound, even in the R6RS
>> modules.  This change is not anticipated to cause any incompatibility
>> with existing Guile code, and improves things for R6RS and R7RS users.
>>
>> ** Conventional gettext alias is now `G_'
>>
>> Related to the last point, since the "Fix literal matching for
>> module-bound literals" change in the 2.2 series, it was no longer
>> possible to use the conventional `_' binding as an alias for `gettext',
>> because a local `_' definition would prevent `_' from being recognized
>> as auxiliary syntax for `match', `syntax-rules', and similar.  The new
>> recommended conventional alias for `gettext' is `G_'.
>>
>> ** Add --r6rs command-line option
>>
>> The new `install-r6rs!' procedure adapts Guile's defaults to be more
>> R6RS-compatible.  This procedure is called if the user passes `--r6rs'
>> as a command-line argument.  See "R6RS Incompatibilities" in the manual,
>> for full details.
>>
>> ** Add support for R7RS
>>
>> Thanks to Göran Weinholt and OKUMURA Yuki, Guile now implements the R7RS
>> modules.  As the R7RS library syntax is a subset of R6RS, to use R7RS
>> you just `(import (scheme base))' and off you go.  As with R6RS also,
>> there are some small lexical incompatibilities regarding hex escapes;
>> see "R6RS Support" in the manual, for full details.
>>
>> Also as with R6RS, there is an `install-r7rs!' procedure and a `--r7rs'
>> command-line option.
>>
>> ** Add #:re-export-and-replace argument to `define-module'
>>
>> This new keyword specifies a set of bindings to re-export, but also
>> marks them as intended to replace core bindings.  See "Creating Guile
>> Modules" in the manual, for full details.
>>
>> Note to make this change, we had to change the way replacement flags are
>> stored, to being associated with modules instead of individual variable
>> objects.  This means that users who #:re-export an imported binding that
>> was already marked as #:replace by another module will now see warnings,
>> as they need to use #:re-export-and-replace instead.
>>
>> ** `iota' in core and SRFI-1 `iota' are the same
>>
>> Previously, `iota' in core would not accept start and step arguments and
>> would return an empty list for negative count. Now there is only one
>> `iota' function with the extended semantics of SRFI-1.  Note that as an
>> incompatible change, core `iota' no longer accepts a negative count.
>>
>> * New deprecations
>>
>> ** scm_t_uint8, etc deprecated in favor of C99 stdint.h
>>
>> It used to be that Guile defined its own `scm_t_uint8' because C99
>> `uint8_t' wasn't widely enough available.  Now Guile finally made the
>> change to use C99 types, both internally and in Guile's public headers.
>>
>> Note that this also applies to SCM_T_UINT8_MAX, SCM_T_INT8_MIN, for intN
>> and uintN for N in 8, 16, 32, and 64.  Guile also now uses ptrdiff_t
>> instead of scm_t_ptrdiff, and similarly for intmax_t, uintmax_t,
>> intptr_t, and uintptr_t.
>>
>> ** The two-argument form of `record-constructor'
>>
>> Calling `record-constructor' with two arguments (the record type and a
>> list of field names) is deprecated.  Instead, call with just one
>> argument, and provide a wrapper around that constructor if needed.
>>
>> * Incompatible changes
>>
>> ** All deprecated code removed
>>
>> All code deprecated in Guile 2.2 has been removed.  See older NEWS, and
>> check that your programs can compile without linker warnings and run
>> without runtime warnings.  See "Deprecation" in the manual.
>>
>> In particular, the function `scm_generalized_vector_get_handle' which
>> was deprecated in 2.0.9 but remained in 2.2, has now finally been
>> removed. As a replacement, use `scm_array_get_handle' to get a handle
>> and `scm_array_handle_rank' to check the rank.
>>
>> ** Remove "self" field from vtables and "redefined" field from classes
>>
>> These fields were used as part of the machinery for class redefinition
>> and is no longer needed.
>>
>> ** VM hook manipulation simplified
>>
>> The low-level mechanism to instrument a running virtual machine for
>> debugging and tracing has been simplified.  See "VM Hooks" in the
>> manual, for more.
>>
>> * Changes to the distribution
>>
>> ** New effective version
>>
>> The "effective version" of Guile is now 3.0, which allows parallel
>> installation with other effective versions (for example, the older Guile
>> 2.2).  See "Parallel Installations" in the manual for full details.
>> Notably, the `pkg-config' file is now `guile-3.0', and there are new
>> `guile-3' and `guile-3.0' features for `cond-expand'.
>>
>>

[-- Attachment #2: Type: text/html, Size: 24310 bytes --]

Re: GNU Guile 2.9.9 Released [beta]

[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.itampe@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)
>
> ;;; (#<procedure eq? (#:optional _ _ . _)> #f)
>
> ;;; (#<procedure eqv? (#:optional _ _ . _)> #f)
>
> ;;; (#<procedure equal? (#:optional _ _ . _)> #f)
>
> ;;; (139824931374184 139824931374200)
>
>
> On Mon, Jan 13, 2020 at 9:39 AM Andy Wingo <wingo@pobox.com> 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-guile@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 stack to the
>> cond clauses, then rewind if none match.  This is not only quite
>> expensive, it is also error-prone as one usually doesn't want to rewind
>> dynamic-wind guards in an exceptional situation.  Additionally, as
>> continuations bind tightly to the current thread, it makes it impossible
>> to migrate a subcomputation with a different thread if a `guard' is live
>> on the stack, as is done in Fibers.
>>
>> 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.
>>
>> ** Improve SRFI-43 vector-fill!
>>
>> SRFI-43 vector-fill! now has the same performance whether an optional
>> range is provided or not, and is also provided in core.  As a side
>> effect, vector-fill! and vector_fill_x no longer work on non-vector
>> rank-1 arrays.  Such cases were handled incorrectly before; for example,
>> prior to this change:
>>
>>   (define a (make-vector 10 'x))
>>   (define b (make-shared-array a (lambda (i) (list (* 2 i))) 5))
>>   (vector-fill! b 'y)
>>
>>   => #1(y y y x x)
>>
>> This is now an error.  Instead, use array-fill!.
>>
>> ** Fix compilation on 32-bit targets
>>
>> A compile error introduced in 2.9.3 prevented compilation on 32-bit
>> targets.  This has been fixed.
>>
>> ** Fix a bug in closure conversion
>>
>> Thanks for Stefan Israelsson Tampe for the report.
>>
>> ** Fix omission in R7RS support
>>
>> Somewhat embarrassingly, the R7RS support added earlier in 2.9 failed to
>> include an implementation of `define-library'.  This oversight has been
>> corrected :)
>>
>> ** Optionally allow duplicate field names in core records
>>
>> See the new #:allow-duplicate-field-names? keyword argument to
>> `make-record-type' in the manual, for more.  This restores a needed
>> feature to R6RS records.
>>
>> ** Fix default value of thread-local fluids
>>
>> Before, `fluid-ref' on an unbound thread-local fluid was returning #f
>> instead of the default value of the fluid.  Thanks to Rob Browning for
>> the fix!
>>
>>
>>
>> Changes in alpha 2.9.x (since the stable 2.2 series):
>>
>> * Notable changes
>>
>> ** 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.
>>
>> See "Just-In-Time Native Code" in the manual, for more information.  JIT
>> compilation will be enabled automatically and transparently.  To disable
>> JIT compilation, configure Guile with `--enable-jit=no' or
>> `--disable-jit'.  The default is `--enable-jit=auto', which enables the
>> JIT if it is available.  See `./configure --help' for more.
>>
>> JIT compilation is enabled by default on x86-64, i686, ARMv7, and
>> AArch64 targets.
>>
>> ** Lower-level bytecode
>>
>> Relative to the virtual machine in Guile 2.2, Guile's VM instruction set
>> is now more low-level.  This allows it to express more advanced
>> optimizations, for example type check elision or integer
>> devirtualization, and makes the task of JIT code generation easier.
>>
>> Note that this change can mean that for a given function, the
>> corresponding number of instructions in Guile 3.0 may be higher than
>> Guile 2.2, which can lead to slowdowns when the function is interpreted.
>> We hope that JIT compilation more than makes up for this slight
>> slowdown.
>>
>> ** Interleaved internal definitions and expressions allowed
>>
>> It used to be that internal definitions had to precede all expressions
>> in their bodies.  This restriction has been relaxed.  If an expression
>> precedes an internal definition, it is treated as if it were a
>> definition of an unreferenced variable.  For example, the expression
>> `(foo)' transforms to the equivalent of `(define _ (begin (foo) #f))',
>> if it precedes other definitions.
>>
>> This change improves the readability of Guile programs, as it used to be
>> that program indentation tended to increase needlessly to allow nested
>> `let' and `letrec' to re-establish definition contexts after initial
>> expressions, for example for type-checks on procedure arguments.
>>
>> ** Record unification
>>
>> Guile used to have a number of implementations of structured data types
>> in the form of "records": a core facility, SRFI-9 (records), SRFI-35
>> (condition types -- a form of records) and R6RS records.  These
>> facilities were not compatible, as they all were built in different
>> ways.  This had the unfortunate corollary that SRFI-35 conditions were
>> not compatible with R6RS conditions.  To fix this problem, we have now
>> added the union of functionality from all of these record types into
>> core records: single-inheritance subtyping, mutable and immutable
>> fields, and so on.  See "Records" in the manual, for full details.
>>
>> R6RS records, SRFI-9 records, and the SRFI-35 and R6RS exception types
>> have been accordingly "rebased" on top of core records.
>>
>> ** Reimplementation of exceptions
>>
>> Since Guile's origins 25 years ago, `throw' and `catch' have been the
>> primary exception-handling primitives.  However these primitives have
>> two problems.  One is that it's hard to handle exceptions in a
>> structured way using `catch'.  Few people remember what the
>> corresponding `key' and `args' are that an exception handler would see
>> in response to a call to `error', for example.  In practice, this
>> results in more generic catch-all exception handling than one might
>> like.
>>
>> The other problem is that `throw', `catch', and especially
>> `with-throw-handler' are quite unlike what the rest of the Scheme world
>> uses.  R6RS and R7RS, for example, have mostly converged on
>> SRFI-34-style `with-exception-handler' and `raise' primitives, and
>> encourage the use of SRFI-35-style structured exception objects to
>> describe the error.  Guile's R6RS layer incorporates an adapter between
>> `throw'/`catch' and structured exception handling, but it didn't apply
>> to SRFI-34/SRFI-35, and we would have to duplicate it for R7RS.
>>
>> In light of these considerations, Guile has now changed to make
>> `with-exception-handler' and `raise-exception' its primitives for
>> exception handling and defined a hierarchy of R6RS-style exception types
>> in its core.  SRFI-34/35, R6RS, and the exception-handling components of
>> SRFI-18 (threads) have been re-implemented in terms of this core
>> functionality.  There is also a a compatibility layer that makes it so
>> that exceptions originating in `throw' can be handled by
>> `with-exception-hander', and vice-versa for `raise-exception' and
>> `catch'.
>>
>> Generally speaking, users will see no difference.  The one significant
>> difference is that users of SRFI-34 will see more exceptions flowing
>> through their `with-exception-handler'/`guard' forms, because whereas
>> before they would only see exceptions thrown by SRFI-34, now they will
>> see exceptions thrown by R6RS, R7RS, or indeed `throw'.
>>
>> Guile's situation is transitional.  Most exceptions are still signalled
>> via `throw'.  These will probably migrate over time to
>> `raise-exception', while preserving compatibility of course.
>>
>> See "Exceptions" in the manual, for full details on the new API.
>>
>> ** Optimization of top-level bindings within a compilation unit
>>
>> At optimization level 2 and above, Guile's compiler is now allowed to
>> inline top-level definitions within a compilation unit.  See
>> "Declarative Modules" in the manual, for full details.  This change can
>> improve the performance of programs with many small top-level
>> definitions by quite a bit!
>>
>> At optimization level 3 and above, Guile will assume that any top-level
>> binding in a declarative compilation unit that isn't exported from a
>> module can be completely inlined into its uses.  (Prior to this change,
>> -O3 was the same as -O2.)  Note that with this new
>> `seal-private-bindings' pass, private declarative bindings are no longer
>> available for access from the first-class module reflection API.  The
>> optimizations afforded by this pass can be useful when you need a speed
>> boost, but having them enabled at optimization level 3 means they are
>> not on by default, as they change Guile's behavior in ways that users
>> might not expect.
>>
>> ** By default, GOOPS classes are not redefinable
>>
>> It used to be that all GOOPS classes were redefinable, at least in
>> theory.  This facility was supported by an indirection in all "struct"
>> instances, even though only a subset of structs would need redefinition.
>> We wanted to remove this indirection, in order to speed up Guile
>> records, allow immutable Guile records to eventually be described by
>> classes, and allow for some optimizations in core GOOPS classes that
>> shouldn't be redefined anyway.
>>
>> Thus in GOOPS now there are classes that are redefinable and classes
>> that aren't.  By default, classes created with GOOPS are not
>> redefinable.  To make a class redefinable, it should be an instance of
>> `<redefinable-class>'.  See "Redefining a Class" in the manual for more
>> information.
>>
>> ** Define top-level bindings for aux syntax: `else', `=>', `...', `_'
>>
>> These auxiliary syntax definitions are specified to be defined in the
>> R6RS and the R7RS.  They were previously unbound, even in the R6RS
>> modules.  This change is not anticipated to cause any incompatibility
>> with existing Guile code, and improves things for R6RS and R7RS users.
>>
>> ** Conventional gettext alias is now `G_'
>>
>> Related to the last point, since the "Fix literal matching for
>> module-bound literals" change in the 2.2 series, it was no longer
>> possible to use the conventional `_' binding as an alias for `gettext',
>> because a local `_' definition would prevent `_' from being recognized
>> as auxiliary syntax for `match', `syntax-rules', and similar.  The new
>> recommended conventional alias for `gettext' is `G_'.
>>
>> ** Add --r6rs command-line option
>>
>> The new `install-r6rs!' procedure adapts Guile's defaults to be more
>> R6RS-compatible.  This procedure is called if the user passes `--r6rs'
>> as a command-line argument.  See "R6RS Incompatibilities" in the manual,
>> for full details.
>>
>> ** Add support for R7RS
>>
>> Thanks to Göran Weinholt and OKUMURA Yuki, Guile now implements the R7RS
>> modules.  As the R7RS library syntax is a subset of R6RS, to use R7RS
>> you just `(import (scheme base))' and off you go.  As with R6RS also,
>> there are some small lexical incompatibilities regarding hex escapes;
>> see "R6RS Support" in the manual, for full details.
>>
>> Also as with R6RS, there is an `install-r7rs!' procedure and a `--r7rs'
>> command-line option.
>>
>> ** Add #:re-export-and-replace argument to `define-module'
>>
>> This new keyword specifies a set of bindings to re-export, but also
>> marks them as intended to replace core bindings.  See "Creating Guile
>> Modules" in the manual, for full details.
>>
>> Note to make this change, we had to change the way replacement flags are
>> stored, to being associated with modules instead of individual variable
>> objects.  This means that users who #:re-export an imported binding that
>> was already marked as #:replace by another module will now see warnings,
>> as they need to use #:re-export-and-replace instead.
>>
>> ** `iota' in core and SRFI-1 `iota' are the same
>>
>> Previously, `iota' in core would not accept start and step arguments and
>> would return an empty list for negative count. Now there is only one
>> `iota' function with the extended semantics of SRFI-1.  Note that as an
>> incompatible change, core `iota' no longer accepts a negative count.
>>
>> * New deprecations
>>
>> ** scm_t_uint8, etc deprecated in favor of C99 stdint.h
>>
>> It used to be that Guile defined its own `scm_t_uint8' because C99
>> `uint8_t' wasn't widely enough available.  Now Guile finally made the
>> change to use C99 types, both internally and in Guile's public headers.
>>
>> Note that this also applies to SCM_T_UINT8_MAX, SCM_T_INT8_MIN, for intN
>> and uintN for N in 8, 16, 32, and 64.  Guile also now uses ptrdiff_t
>> instead of scm_t_ptrdiff, and similarly for intmax_t, uintmax_t,
>> intptr_t, and uintptr_t.
>>
>> ** The two-argument form of `record-constructor'
>>
>> Calling `record-constructor' with two arguments (the record type and a
>> list of field names) is deprecated.  Instead, call with just one
>> argument, and provide a wrapper around that constructor if needed.
>>
>> * Incompatible changes
>>
>> ** All deprecated code removed
>>
>> All code deprecated in Guile 2.2 has been removed.  See older NEWS, and
>> check that your programs can compile without linker warnings and run
>> without runtime warnings.  See "Deprecation" in the manual.
>>
>> In particular, the function `scm_generalized_vector_get_handle' which
>> was deprecated in 2.0.9 but remained in 2.2, has now finally been
>> removed. As a replacement, use `scm_array_get_handle' to get a handle
>> and `scm_array_handle_rank' to check the rank.
>>
>> ** Remove "self" field from vtables and "redefined" field from classes
>>
>> These fields were used as part of the machinery for class redefinition
>> and is no longer needed.
>>
>> ** VM hook manipulation simplified
>>
>> The low-level mechanism to instrument a running virtual machine for
>> debugging and tracing has been simplified.  See "VM Hooks" in the
>> manual, for more.
>>
>> * Changes to the distribution
>>
>> ** New effective version
>>
>> The "effective version" of Guile is now 3.0, which allows parallel
>> installation with other effective versions (for example, the older Guile
>> 2.2).  See "Parallel Installations" in the manual for full details.
>> Notably, the `pkg-config' file is now `guile-3.0', and there are new
>> `guile-3' and `guile-3.0' features for `cond-expand'.
>>
>>

Re: GNU Guile 2.9.9 Released [beta]

[Andy Wingo]

On Mon 13 Jan 2020 22:32, Stefan Israelsson Tampe <stefan.itampe@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

Fwd: GNU Guile 2.9.9 Released [beta]

[Stefan Israelsson Tampe]

[-- Attachment #1: Type: text/plain, Size: 1977 bytes --]

---------- Forwarded message ---------
From: Stefan Israelsson Tampe <stefan.itampe@gmail.com>
Date: Tue, Jan 14, 2020 at 12:43 PM
Subject: Re: GNU Guile 2.9.9 Released [beta]
To: Andy Wingo <wingo@pobox.com>


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 <wingo@pobox.com> wrote:

> On Mon 13 Jan 2020 22:32, Stefan Israelsson Tampe <stefan.itampe@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
>

[-- Attachment #2: Type: text/html, Size: 3011 bytes --]

Re: GNU Guile 2.9.9 Released [beta]

[Mikael Djurfeldt]

[-- Attachment #1: Type: text/plain, Size: 2232 bytes --]

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 <wingo@pobox.com> skrev:

> On Mon 13 Jan 2020 22:32, Stefan Israelsson Tampe <stefan.itampe@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
>
>

[-- Attachment #2: Type: text/html, Size: 3154 bytes --]

Re: GNU Guile 2.9.9 Released [beta]

[Stefan Israelsson Tampe]

[-- Attachment #1: Type: text/plain, Size: 2856 bytes --]

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 <mikael@djurfeldt.com>
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 <wingo@pobox.com> skrev:
>
>> On Mon 13 Jan 2020 22:32, Stefan Israelsson Tampe <
>> stefan.itampe@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
>>
>>

[-- Attachment #2: Type: text/html, Size: 4141 bytes --]

Re: GNU Guile 2.9.9 Released [beta]

[Andy Wingo]

On Tue 14 Jan 2020 13:18, Mikael Djurfeldt <mikael@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))

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]

[Stefan Israelsson Tampe]

[-- Attachment #1: Type: text/plain, Size: 2453 bytes --]

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 <wingo@pobox.com> wrote:

> On Tue 14 Jan 2020 13:18, Mikael Djurfeldt <mikael@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))
>
> 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
>
>

[-- Attachment #2: Type: text/html, Size: 3235 bytes --]

Re: GNU Guile 2.9.9 Released [beta]

[Andy Wingo]

On Tue 14 Jan 2020 15:47, Stefan Israelsson Tampe <stefan.itampe@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]

[Stefan Israelsson Tampe]

[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]

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 <wingo@pobox.com> wrote:

> On Tue 14 Jan 2020 15:47, Stefan Israelsson Tampe <stefan.itampe@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
>

[-- Attachment #2: Type: text/html, Size: 2581 bytes --]

Re: GNU Guile 2.9.9 Released [beta]

[Stefan Israelsson Tampe]

[-- Attachment #1: Type: text/plain, Size: 1832 bytes --]

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.itampe@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 <wingo@pobox.com> wrote:
>
>> On Tue 14 Jan 2020 15:47, Stefan Israelsson Tampe <
>> stefan.itampe@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
>>
>

[-- Attachment #2: Type: text/html, Size: 3104 bytes --]

Re: GNU Guile 2.9.9 Released [beta]

[Mikael Djurfeldt]

[-- Attachment #1: Type: text/plain, Size: 2449 bytes --]

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 <wingo@pobox.com> skrev:

> On Tue 14 Jan 2020 13:18, Mikael Djurfeldt <mikael@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))
>
> 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
>

[-- Attachment #2: Type: text/html, Size: 3353 bytes --]

Fwd: GNU Guile 2.9.9 Released [beta]

[Stefan Israelsson Tampe]

[-- Attachment #1: Type: text/plain, Size: 3803 bytes --]

---------- Forwarded message ---------
From: Stefan Israelsson Tampe <stefan.itampe@gmail.com>
Date: Tue, Jan 14, 2020 at 5:23 PM
Subject: Re: GNU Guile 2.9.9 Released [beta]
To: Mikael Djurfeldt <mikael@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 <mikael@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 <wingo@pobox.com> skrev:
>
>> On Tue 14 Jan 2020 13:18, Mikael Djurfeldt <mikael@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))
>>
>> 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
>>
>

[-- Attachment #2: Type: text/html, Size: 5265 bytes --]

Re: GNU Guile 2.9.9 Released [beta]

[Mikael Djurfeldt]

[-- Attachment #1: Type: text/plain, Size: 4561 bytes --]

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.itampe@gmail.com> wrote:

>
>
> ---------- Forwarded message ---------
> From: Stefan Israelsson Tampe <stefan.itampe@gmail.com>
> Date: Tue, Jan 14, 2020 at 5:23 PM
> Subject: Re: GNU Guile 2.9.9 Released [beta]
> To: Mikael Djurfeldt <mikael@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 <mikael@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 <wingo@pobox.com> skrev:
>>
>>> On Tue 14 Jan 2020 13:18, Mikael Djurfeldt <mikael@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))
>>>
>>> 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
>>>
>>

[-- Attachment #2: Type: text/html, Size: 6326 bytes --]

Re: GNU Guile 2.9.9 Released [beta]

[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
> <stefan.itampe@gmail.com <mailto:stefan.itampe@gmail.com>> wrote:
> 
> 
> 
>     ---------- Forwarded message ---------
>     From: *Stefan Israelsson Tampe* <stefan.itampe@gmail.com
>     <mailto:stefan.itampe@gmail.com>>
>     Date: Tue, Jan 14, 2020 at 5:23 PM
>     Subject: Re: GNU Guile 2.9.9 Released [beta]
>     To: Mikael Djurfeldt <mikael@djurfeldt.com
>     <mailto:mikael@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
>     <mikael@djurfeldt.com <mailto:mikael@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 <wingo@pobox.com
>         <mailto:wingo@pobox.com>> skrev:
> 
>             On Tue 14 Jan 2020 13:18, Mikael Djurfeldt
>             <mikael@djurfeldt.com <mailto:mikael@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))
> 
>             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]

[Stefan Israelsson Tampe]

[-- Attachment #1: Type: text/plain, Size: 5569 bytes --]

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 <mikael@djurfeldt.com>
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.itampe@gmail.com> wrote:
>
>>
>>
>> ---------- Forwarded message ---------
>> From: Stefan Israelsson Tampe <stefan.itampe@gmail.com>
>> Date: Tue, Jan 14, 2020 at 5:23 PM
>> Subject: Re: GNU Guile 2.9.9 Released [beta]
>> To: Mikael Djurfeldt <mikael@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 <mikael@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 <wingo@pobox.com> skrev:
>>>
>>>> On Tue 14 Jan 2020 13:18, Mikael Djurfeldt <mikael@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))
>>>>
>>>> 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
>>>>
>>>

[-- Attachment #2: Type: text/html, Size: 7625 bytes --]

Re: GNU Guile 2.9.9 Released [beta]

[Andy Wingo]

On Tue 14 Jan 2020 17:03, Mikael Djurfeldt <mikael@djurfeldt.com> 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]

[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 <wingo@pobox.com> 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-guile@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 stack to the
> cond clauses, then rewind if none match.  This is not only quite
> expensive, it is also error-prone as one usually doesn't want to rewind
> dynamic-wind guards in an exceptional situation.  Additionally, as
> continuations bind tightly to the current thread, it makes it impossible
> to migrate a subcomputation with a different thread if a `guard' is live
> on the stack, as is done in Fibers.
>
> 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.
>
> ** Improve SRFI-43 vector-fill!
>
> SRFI-43 vector-fill! now has the same performance whether an optional
> range is provided or not, and is also provided in core.  As a side
> effect, vector-fill! and vector_fill_x no longer work on non-vector
> rank-1 arrays.  Such cases were handled incorrectly before; for example,
> prior to this change:
>
>   (define a (make-vector 10 'x))
>   (define b (make-shared-array a (lambda (i) (list (* 2 i))) 5))
>   (vector-fill! b 'y)
>
>   => #1(y y y x x)
>
> This is now an error.  Instead, use array-fill!.
>
> ** Fix compilation on 32-bit targets
>
> A compile error introduced in 2.9.3 prevented compilation on 32-bit
> targets.  This has been fixed.
>
> ** Fix a bug in closure conversion
>
> Thanks for Stefan Israelsson Tampe for the report.
>
> ** Fix omission in R7RS support
>
> Somewhat embarrassingly, the R7RS support added earlier in 2.9 failed to
> include an implementation of `define-library'.  This oversight has been
> corrected :)
>
> ** Optionally allow duplicate field names in core records
>
> See the new #:allow-duplicate-field-names? keyword argument to
> `make-record-type' in the manual, for more.  This restores a needed
> feature to R6RS records.
>
> ** Fix default value of thread-local fluids
>
> Before, `fluid-ref' on an unbound thread-local fluid was returning #f
> instead of the default value of the fluid.  Thanks to Rob Browning for
> the fix!
>
>
>
> Changes in alpha 2.9.x (since the stable 2.2 series):
>
> * Notable changes
>
> ** 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.
>
> See "Just-In-Time Native Code" in the manual, for more information.  JIT
> compilation will be enabled automatically and transparently.  To disable
> JIT compilation, configure Guile with `--enable-jit=no' or
> `--disable-jit'.  The default is `--enable-jit=auto', which enables the
> JIT if it is available.  See `./configure --help' for more.
>
> JIT compilation is enabled by default on x86-64, i686, ARMv7, and
> AArch64 targets.
>
> ** Lower-level bytecode
>
> Relative to the virtual machine in Guile 2.2, Guile's VM instruction set
> is now more low-level.  This allows it to express more advanced
> optimizations, for example type check elision or integer
> devirtualization, and makes the task of JIT code generation easier.
>
> Note that this change can mean that for a given function, the
> corresponding number of instructions in Guile 3.0 may be higher than
> Guile 2.2, which can lead to slowdowns when the function is interpreted.
> We hope that JIT compilation more than makes up for this slight
> slowdown.
>
> ** Interleaved internal definitions and expressions allowed
>
> It used to be that internal definitions had to precede all expressions
> in their bodies.  This restriction has been relaxed.  If an expression
> precedes an internal definition, it is treated as if it were a
> definition of an unreferenced variable.  For example, the expression
> `(foo)' transforms to the equivalent of `(define _ (begin (foo) #f))',
> if it precedes other definitions.
>
> This change improves the readability of Guile programs, as it used to be
> that program indentation tended to increase needlessly to allow nested
> `let' and `letrec' to re-establish definition contexts after initial
> expressions, for example for type-checks on procedure arguments.
>
> ** Record unification
>
> Guile used to have a number of implementations of structured data types
> in the form of "records": a core facility, SRFI-9 (records), SRFI-35
> (condition types -- a form of records) and R6RS records.  These
> facilities were not compatible, as they all were built in different
> ways.  This had the unfortunate corollary that SRFI-35 conditions were
> not compatible with R6RS conditions.  To fix this problem, we have now
> added the union of functionality from all of these record types into
> core records: single-inheritance subtyping, mutable and immutable
> fields, and so on.  See "Records" in the manual, for full details.
>
> R6RS records, SRFI-9 records, and the SRFI-35 and R6RS exception types
> have been accordingly "rebased" on top of core records.
>
> ** Reimplementation of exceptions
>
> Since Guile's origins 25 years ago, `throw' and `catch' have been the
> primary exception-handling primitives.  However these primitives have
> two problems.  One is that it's hard to handle exceptions in a
> structured way using `catch'.  Few people remember what the
> corresponding `key' and `args' are that an exception handler would see
> in response to a call to `error', for example.  In practice, this
> results in more generic catch-all exception handling than one might
> like.
>
> The other problem is that `throw', `catch', and especially
> `with-throw-handler' are quite unlike what the rest of the Scheme world
> uses.  R6RS and R7RS, for example, have mostly converged on
> SRFI-34-style `with-exception-handler' and `raise' primitives, and
> encourage the use of SRFI-35-style structured exception objects to
> describe the error.  Guile's R6RS layer incorporates an adapter between
> `throw'/`catch' and structured exception handling, but it didn't apply
> to SRFI-34/SRFI-35, and we would have to duplicate it for R7RS.
>
> In light of these considerations, Guile has now changed to make
> `with-exception-handler' and `raise-exception' its primitives for
> exception handling and defined a hierarchy of R6RS-style exception types
> in its core.  SRFI-34/35, R6RS, and the exception-handling components of
> SRFI-18 (threads) have been re-implemented in terms of this core
> functionality.  There is also a a compatibility layer that makes it so
> that exceptions originating in `throw' can be handled by
> `with-exception-hander', and vice-versa for `raise-exception' and
> `catch'.
>
> Generally speaking, users will see no difference.  The one significant
> difference is that users of SRFI-34 will see more exceptions flowing
> through their `with-exception-handler'/`guard' forms, because whereas
> before they would only see exceptions thrown by SRFI-34, now they will
> see exceptions thrown by R6RS, R7RS, or indeed `throw'.
>
> Guile's situation is transitional.  Most exceptions are still signalled
> via `throw'.  These will probably migrate over time to
> `raise-exception', while preserving compatibility of course.
>
> See "Exceptions" in the manual, for full details on the new API.
>
> ** Optimization of top-level bindings within a compilation unit
>
> At optimization level 2 and above, Guile's compiler is now allowed to
> inline top-level definitions within a compilation unit.  See
> "Declarative Modules" in the manual, for full details.  This change can
> improve the performance of programs with many small top-level
> definitions by quite a bit!
>
> At optimization level 3 and above, Guile will assume that any top-level
> binding in a declarative compilation unit that isn't exported from a
> module can be completely inlined into its uses.  (Prior to this change,
> -O3 was the same as -O2.)  Note that with this new
> `seal-private-bindings' pass, private declarative bindings are no longer
> available for access from the first-class module reflection API.  The
> optimizations afforded by this pass can be useful when you need a speed
> boost, but having them enabled at optimization level 3 means they are
> not on by default, as they change Guile's behavior in ways that users
> might not expect.
>
> ** By default, GOOPS classes are not redefinable
>
> It used to be that all GOOPS classes were redefinable, at least in
> theory.  This facility was supported by an indirection in all "struct"
> instances, even though only a subset of structs would need redefinition.
> We wanted to remove this indirection, in order to speed up Guile
> records, allow immutable Guile records to eventually be described by
> classes, and allow for some optimizations in core GOOPS classes that
> shouldn't be redefined anyway.
>
> Thus in GOOPS now there are classes that are redefinable and classes
> that aren't.  By default, classes created with GOOPS are not
> redefinable.  To make a class redefinable, it should be an instance of
> `<redefinable-class>'.  See "Redefining a Class" in the manual for more
> information.
>
> ** Define top-level bindings for aux syntax: `else', `=>', `...', `_'
>
> These auxiliary syntax definitions are specified to be defined in the
> R6RS and the R7RS.  They were previously unbound, even in the R6RS
> modules.  This change is not anticipated to cause any incompatibility
> with existing Guile code, and improves things for R6RS and R7RS users.
>
> ** Conventional gettext alias is now `G_'
>
> Related to the last point, since the "Fix literal matching for
> module-bound literals" change in the 2.2 series, it was no longer
> possible to use the conventional `_' binding as an alias for `gettext',
> because a local `_' definition would prevent `_' from being recognized
> as auxiliary syntax for `match', `syntax-rules', and similar.  The new
> recommended conventional alias for `gettext' is `G_'.
>
> ** Add --r6rs command-line option
>
> The new `install-r6rs!' procedure adapts Guile's defaults to be more
> R6RS-compatible.  This procedure is called if the user passes `--r6rs'
> as a command-line argument.  See "R6RS Incompatibilities" in the manual,
> for full details.
>
> ** Add support for R7RS
>
> Thanks to Göran Weinholt and OKUMURA Yuki, Guile now implements the R7RS
> modules.  As the R7RS library syntax is a subset of R6RS, to use R7RS
> you just `(import (scheme base))' and off you go.  As with R6RS also,
> there are some small lexical incompatibilities regarding hex escapes;
> see "R6RS Support" in the manual, for full details.
>
> Also as with R6RS, there is an `install-r7rs!' procedure and a `--r7rs'
> command-line option.
>
> ** Add #:re-export-and-replace argument to `define-module'
>
> This new keyword specifies a set of bindings to re-export, but also
> marks them as intended to replace core bindings.  See "Creating Guile
> Modules" in the manual, for full details.
>
> Note to make this change, we had to change the way replacement flags are
> stored, to being associated with modules instead of individual variable
> objects.  This means that users who #:re-export an imported binding that
> was already marked as #:replace by another module will now see warnings,
> as they need to use #:re-export-and-replace instead.
>
> ** `iota' in core and SRFI-1 `iota' are the same
>
> Previously, `iota' in core would not accept start and step arguments and
> would return an empty list for negative count. Now there is only one
> `iota' function with the extended semantics of SRFI-1.  Note that as an
> incompatible change, core `iota' no longer accepts a negative count.
>
> * New deprecations
>
> ** scm_t_uint8, etc deprecated in favor of C99 stdint.h
>
> It used to be that Guile defined its own `scm_t_uint8' because C99
> `uint8_t' wasn't widely enough available.  Now Guile finally made the
> change to use C99 types, both internally and in Guile's public headers.
>
> Note that this also applies to SCM_T_UINT8_MAX, SCM_T_INT8_MIN, for intN
> and uintN for N in 8, 16, 32, and 64.  Guile also now uses ptrdiff_t
> instead of scm_t_ptrdiff, and similarly for intmax_t, uintmax_t,
> intptr_t, and uintptr_t.
>
> ** The two-argument form of `record-constructor'
>
> Calling `record-constructor' with two arguments (the record type and a
> list of field names) is deprecated.  Instead, call with just one
> argument, and provide a wrapper around that constructor if needed.
>
> * Incompatible changes
>
> ** All deprecated code removed
>
> All code deprecated in Guile 2.2 has been removed.  See older NEWS, and
> check that your programs can compile without linker warnings and run
> without runtime warnings.  See "Deprecation" in the manual.
>
> In particular, the function `scm_generalized_vector_get_handle' which
> was deprecated in 2.0.9 but remained in 2.2, has now finally been
> removed. As a replacement, use `scm_array_get_handle' to get a handle
> and `scm_array_handle_rank' to check the rank.
>
> ** Remove "self" field from vtables and "redefined" field from classes
>
> These fields were used as part of the machinery for class redefinition
> and is no longer needed.
>
> ** VM hook manipulation simplified
>
> The low-level mechanism to instrument a running virtual machine for
> debugging and tracing has been simplified.  See "VM Hooks" in the
> manual, for more.
>
> * Changes to the distribution
>
> ** New effective version
>
> The "effective version" of Guile is now 3.0, which allows parallel
> installation with other effective versions (for example, the older Guile
> 2.2).  See "Parallel Installations" in the manual for full details.
> Notably, the `pkg-config' file is now `guile-3.0', and there are new
> `guile-3' and `guile-3.0' features for `cond-expand'.
>
>

Re: GNU Guile 2.9.9 Released [beta]

[Andy Wingo]

On Tue 14 Jan 2020 21:13, Stefan Israelsson Tampe <stefan.itampe@gmail.com> 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]

[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 <wingo@pobox.com> wrote:

> On Tue 14 Jan 2020 21:13, Stefan Israelsson Tampe <stefan.itampe@gmail.com>
> 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]

[Andy Wingo]

On Tue 14 Jan 2020 22:48, Stefan Israelsson Tampe <stefan.itampe@gmail.com> 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: bug#39118: Segfault while building on 64-bit Cygwin

[dsmich]

[-- Attachment #1: Type: text/plain, Size: 2052 bytes --]

Pretty sure that the missing readline symbol is because the macos
readline is being used/found instead of GNU readline.

	-Dale

	-----------------------------------------From: "John Cowan" 
To: "Ludovic Courtès"
Cc: 39118@debbugs.gnu.org, guile-devel@gnu.org
Sent: Friday January 24 2020 9:36:59AM
Subject: bug#39118: Segfault while building on 64-bit Cygwin

Both Cygwin and MacOS crash in pretty much the same way. By disabling
the JIT, I was able to get the Cygwin build to run to completion. On
MacOS with --disable-jit, however, I am now getting an entirely new
failure:
 CC readline.lo
readline.c:432:7: warning: implicitly declaring library function
'strncmp' with type 'int (const char *, const char *,
 unsigned long)' [-Wimplicit-function-declaration]
 if (strncmp (rl_get_keymap_name (rl_get_keymap ()), "vi", 2))
 ^
readline.c:432:7: note: include the header  or explicitly provide a
declaration for 'strncmp'
readline.c:432:16: warning: implicit declaration of function
'rl_get_keymap_name' is invalid in C99
 [-Wimplicit-function-declaration]
 if (strncmp (rl_get_keymap_name (rl_get_keymap ()), "vi", 2))
 ^
readline.c:432:16: warning: incompatible integer to pointer conversion
passing 'int' to parameter of type 'const char *'
 [-Wint-conversion]
 if (strncmp (rl_get_keymap_name (rl_get_keymap ()), "vi", 2))
 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3 warnings generated.
 CCLD guile-readline.la [1]
Undefined symbols for architecture x86_64:
 "_rl_get_keymap_name", referenced from:
 _scm_init_readline in readline.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)

On Thu, Jan 23, 2020 at 3:35 PM Ludovic Courtès  wrote:
Hi,

 John Cowan  skribis:

 > Thanks. Unfortunately, the standard recipe for making core dumps on
Mac

 This bug report is about Cygwin, not macOS, right? :-)

 Ludo’.
  

Links:
------
[1] http://guile-readline.la
[2] mailto:ludo@gnu.org
[3] mailto:cowan@ccil.org


[-- Attachment #2: Type: text/html, Size: 2891 bytes --]