Withdrawal?
John Cowan
(24 Oct 2020 20:54 UTC)
|
Re: Withdrawal?
Arthur A. Gleckler
(24 Oct 2020 20:58 UTC)
|
Re: Withdrawal?
John Cowan
(24 Oct 2020 21:04 UTC)
|
Re: Withdrawal?
Arthur A. Gleckler
(24 Oct 2020 21:10 UTC)
|
Re: Withdrawal?
John Cowan
(24 Oct 2020 22:20 UTC)
|
Re: Withdrawal?
Emmanuel Medernach
(25 Oct 2020 15:44 UTC)
|
Re: Withdrawal?
Arthur A. Gleckler
(25 Oct 2020 19:32 UTC)
|
Re: Withdrawal?
Emmanuel Medernach
(25 Oct 2020 20:41 UTC)
|
Re: Withdrawal?
Marc Nieper-Wißkirchen
(25 Oct 2020 20:54 UTC)
|
Re: Withdrawal?
Emmanuel Medernach
(26 Oct 2020 20:47 UTC)
|
Re: Withdrawal?
Emmanuel Medernach
(26 Oct 2020 21:08 UTC)
|
Re: Withdrawal?
Marc Nieper-Wißkirchen
(26 Oct 2020 21:33 UTC)
|
Re: Withdrawal?
Emmanuel Medernach
(27 Oct 2020 08:01 UTC)
|
Re: Withdrawal?
Marc Nieper-Wißkirchen
(27 Oct 2020 08:57 UTC)
|
Re: Withdrawal?
Emmanuel Medernach
(27 Oct 2020 20:44 UTC)
|
Re: Withdrawal?
Wolfgang Corcoran-Mathe
(25 Oct 2020 01:53 UTC)
|
Re: Withdrawal?
Marc Nieper-Wißkirchen
(25 Oct 2020 07:56 UTC)
|
Re: Withdrawal?
John Cowan
(25 Oct 2020 14:40 UTC)
|
Re: Withdrawal?
Wolfgang Corcoran-Mathe
(26 Oct 2020 18:07 UTC)
|
Re: Withdrawal?
Marc Nieper-Wißkirchen
(26 Oct 2020 18:12 UTC)
|
Re: Withdrawal?
John Cowan
(26 Oct 2020 22:19 UTC)
|
Re: Withdrawal?
Wolfgang Corcoran-Mathe
(27 Oct 2020 01:17 UTC)
|
Re: Withdrawal?
John Cowan
(27 Oct 2020 02:30 UTC)
|
Re: Withdrawal?
Marc Nieper-Wißkirchen
(27 Oct 2020 07:01 UTC)
|
Re: Withdrawal?
Wolfgang Corcoran-Mathe
(28 Oct 2020 16:53 UTC)
|
Re: Withdrawal?
John Cowan
(28 Oct 2020 18:35 UTC)
|
Re: Withdrawal?
Wolfgang Corcoran-Mathe
(28 Oct 2020 18:38 UTC)
|
Re: Withdrawal?
Lucier, Bradley J
(28 Oct 2020 18:37 UTC)
|
Re: Withdrawal?
Marc Nieper-Wißkirchen
(27 Oct 2020 06:58 UTC)
|
Re: Withdrawal?
Wolfgang Corcoran-Mathe
(27 Oct 2020 17:37 UTC)
|
Re: Withdrawal?
Marc Nieper-Wißkirchen
(27 Oct 2020 20:17 UTC)
|
Re: Withdrawal?
Wolfgang Corcoran-Mathe
(27 Oct 2020 22:30 UTC)
|
Re: Withdrawal?
Arthur A. Gleckler
(27 Oct 2020 23:49 UTC)
|
Re: Withdrawal?
Marc Nieper-Wißkirchen
(28 Oct 2020 06:17 UTC)
|
Re: Withdrawal?
John Cowan
(28 Oct 2020 15:09 UTC)
|
Re: Withdrawal? Marc Nieper-Wißkirchen (28 Oct 2020 17:04 UTC)
|
Just to be clear. In my last post, I wasn't talking about conformance to the SRFI process (as John and Arthur, I don't see a problem here), I was talking about implications of inclusion into R7RS-large. Am Mi., 28. Okt. 2020 um 16:09 Uhr schrieb John Cowan <xxxxxx@ccil.org>: > > There seem to be several senses of "portability" involved here: > > 1) Portability of the Scheme code between implementations. I think it is clear that this has to be abandoned in favor of something else. > > 2) Portability to difficult ISAs. If they don't do IEEE floats at all, either they have to emulate them in software, or it's hopeless. If (like a few ARM designs) they have different endianness for double and uint64 types, it can be done, but it's not clear that it's worth doing for such an edge case. > > 3) Portability *of* a particular Scheme implementation to various machine-vendor-OS triplets. I don't understand the relevance of this, except insofar as it is relevant to 2. > > 4) Portability to different C standards. It is certainly possible to construct a well-chosen double (not a NaN) and put it in a double/uint64 union and see what integer you get, so that makes it possible in principle to overcome implementation-specific mapping problems. (I did this long ago, unioning a string "\x01\x02\x03\x04" and seeing what came out as a uint32 in order to distinguish between big-, little-, and mixed-endianness.) But overall I think it is safe to treat the behavior as reliable. > > In the end, the responsibility for correctness falls on the implementer of a particular Scheme. The design using C code + FFI that we've been discussing is something between a 7b solution ("A mostly-portable solution that uses some kind of hooks provided in some Scheme interpreter/compiler. In this case, a detailed specification of the hooks must be included so that the SRFI is self-contained.") and a 7c solution ("An implementation-specific solution. Ideally, tricky issues that had to be dealt with in the implementation will be identified."). Both of those are perfectly acceptable per <https://srfi.schemers.org/srfi-process.html> when a fully portable pure Scheme implementation (7a) is not possible. > > > > John Cowan http://vrici.lojban.org/~cowan xxxxxx@ccil.org > And they pack their lyrics till they're so damn dense > You could put 'em in your yard and you could use 'em for a fence. > --Alan Chapman, "Everybody Wants to Be Sondheim"