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