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 20 Jun 2017 23:28 UTC

Arthur A. Gleckler wrote:

> Will, may I remove "srfi-144-constants.scm" now since it's
> redundant with "srfi/144.constants.scm"?

I believe that would be for the best.  Having two nearly identical
lists of multi-digit numbers would be a hazard for maintenance.
The srfi/144.constant.scm file is part of the sample implementation,
while srfi-144-constants.scm isn't used by any other part of the
repository.

John Cowan may have added srfi-144-constants.scm in anticipation of
adding a Chicken-specific implementation.  In my opinion, however,
it is better not to add system-specific code that would inevitably
go out of sync with source code for the one system for which it was
designed.  The srfi/144.ffi.scm and tests/srfi-144-test.scm files are
exceptions proving that rule:  It may be helpful to have one example
showing how many of the procedures could be implemented using an FFI
to C, and srfi/144.ffi.scm might save someone a bit of trouble doing
that.  As for tests/srfi-144-test.scm, I thought it was a good idea
to show how the accuracy and (less importantly) speed of the portable
code could be checked against corresponding C99 functions; besides,
the FFI-dependent part of tests/srfi-144-test.scm should be the only
part of that program that depends on Larceny.

By the way, I forgot to note that the portable sample implementation
was designed to work in R6RS and R5RS with minimal changes.  Indeed,
I did most of the development in Larceny's R5RS mode, where it was
convenient to have access to all of the un-exported help procedures,
including those that ended up being commented out.

Will