This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.
Dr Alan Watson wrote: > No. I am suggesting that you to reconsider your earlier statement that > "most hardware now supports them [flonums] much more efficiently than > they could be implemented in a library module". Please consider it reconsidered. > But, anyway, I don't think this likely to be a useful discussion. > Flonums should be available in Scheme on these platforms. The question > is whether flonums should be in the base language or pushed off into a > library. I would say that flonums are not *needed* in the base language > and so should be pushed off into the library. I would agree with that, if we had a suitable mechanism for such libraries. SRFI-77 was written before SRFI-83, and it isn't clear to me whether SRFI-83 libraries are even adequate for this. SRFI-83 makes no provision for libraries written in languages other than R6RS Scheme, and SRFI-83 explicitly does not require implementations to evaluate library forms interactively, nor does it make any provision for interaction between libraries and the load procedure. Indeed, there does not seem to be any portable way for a Scheme programmer to refer to a SRFI-83 library except from within some other library. I am hopeful that this situation will change, but I do not want SRFI-77 to depend upon changes that have not yet been made to SRFI-83. > Would the following proposal satisfy your goals: > > (a) Mandate unlimited size exact integers in the base language. > > (b) Push fl+ et al. off into a library module. No. The fundamental problem with R5RS arithmetic is that programmers cannot rely on the behavior of the arithmetic primitives. Mandating exact integers of unlimited size would help, but programmers would still not know whether (/ 3 4) will evaluate to 3/4, 0, 1, or 0.75. To solve this problem, we have to require some subset of the tower that has reasonable closure properties, while banishing any arithmetic operations that are not closed over that subset. We have to do both. In my opinion, two fairly extreme positions are the most attractive. Either require the full tower as part of the base language, or require only the fixnum/flonum foundation while banishing + and the other generic operations to the libraries. Will