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)

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"