SRFI 144: more improvements to implementation Arthur A. Gleckler (20 Jun 2017 21:48 UTC)
Re: SRFI 144: more improvements to implementation Arthur A. Gleckler (20 Jun 2017 21:53 UTC)
Re: SRFI 144: more improvements to implementation William D Clinger (20 Jun 2017 23:29 UTC)
Re: SRFI 144: more improvements to implementation Arthur A. Gleckler (21 Jun 2017 00:10 UTC)
Re: SRFI 144: more improvements to implementation John Cowan (21 Jun 2017 01:39 UTC)
Re: SRFI 144: more improvements to implementation William D Clinger (21 Jun 2017 21:01 UTC)
Re: SRFI 144: more improvements to implementation John Cowan (21 Jun 2017 21:20 UTC)
Re: SRFI 144: more improvements to implementation William D Clinger (21 Jun 2017 20:32 UTC)
Re: SRFI 144: more improvements to implementation Bradley Lucier (21 Jun 2017 20:50 UTC)
Re: SRFI 144: more improvements to implementation Bradley Lucier (21 Jun 2017 20:50 UTC)
Re: SRFI 144: more improvements to implementation William D Clinger (21 Jun 2017 21:08 UTC)
Re: SRFI 144: more improvements to implementation John Cowan (21 Jun 2017 21:22 UTC)

Re: SRFI 144: more improvements to implementation William D Clinger 21 Jun 2017 21:01 UTC

Perhaps I should mention once again that the portable sample
implementation runs not only in Larceny but also in other
implementations of R7RS (small).  That has been tested in
Sagittarius, Chibi, Kawa, and Gauche.

Concerning the Chicken-specific srfi-144-constants.scm file,
John Cowan wrote:

> I'm not clear on why it can't just be included in Larceny rather than
> incorporated, but no matter.

The reason it can't be included within the portable sample
implementation is that define-constant is non-portable, so
including that file within the portable implementation would
render the implementation non-portable.  The 144.constants.scm
file is a portable version of the srfi-144-constants.scm file.

You have explained why the portable 144.constants.scm file
fails to accomplish the Chicken-specific purpose you have in
mind, so I guess we have to keep both files despite the
redundancy.

If you really meant to ask why that file can't be included in
Larceny (as opposed to the portable sample implementation),
that file's use of define-constant is reason enough.  I also
note that Larceny's implementation of SRFI 144 will eventually
be quite a bit more complicated than the sample implementation
because Larceny will improve performance using mechanisms such
as inlining and representation inference to eliminate run-time
checking for flonum arguments.

In my opinion, sample implementations should be as portable as
is reasonably practical, with system-specific refinements
residing in the repositories of systems that support the SRFI.

Will