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