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.
arcin 'Qrczak' Kowalczyk wrote: > These points seem to be contradictory: > > > Inexact infinities and NaNs are now assumed to exist. In the > > previous draft, their existence was not always assumed, yet was > > sometimes assumed implicitly. > > > Although implementations of Scheme are not required to represent > > infinities and NaNs I'm going to let the R6RS document editor (Mike Sperber) figure out how to say it better. It should be easier to explain in the larger context of the R6RS. > Examples for div0 and mod0 lack the 0 subscript. Thanks for spotting that. > The whole SRFI is long and has redundant fragments, for example the > table of atan branch cuts is written 3 times. Again, I'm going to let the R6RS document editor sort this out. Concerning duplicate names for operations such as fixnum< and fx<, Marc Feeley wrote: > What is the rationale for all this duplication? See the second rationale in the Fixnums section. > The main motivation for fixnum specific operations is that > they are much faster than generic arithmetic. That is one motivation, and for some people it may be the main motivation, but it is not everyone's main motivation. > But in many implementations of Scheme multiple values are > rather slow... Presumably the operations that return multiple values will be slow in those implementations. Those who regard efficiency as the main motivation for those operations might want to avoid implementations in which multiple values are slow. > Finally, I haven't counted the number of procedures defined > in this SRFI, but it is clearly very high. Do you > realistically think that current implementations of Scheme > will be updated to implement all these procedures efficiently? Inasmuch as most current implementations have not yet gotten around to implementing all of the R5RS procedures efficiently, it would surprise me if they were to implement all of the R6RS procedures efficiently. > Can we expect a portable and reasonably efficient implementation > of this SRFI to be written as the reference implementation? Yes. I'm working on it. A relatively small subset of the fixnum and flonum procedures will be identified as the basic primitives. If implementors implement those primitives efficiently, they will be rewarded with a reasonably efficient implementation of the full SRFI. The reference implementation won't make multiple values any faster, but it should provide multiple implementations of the procedures that would most naturally use them, so systems in which multiple values are fast can benefit from using them and systems in which multiple values are slow can eschew them. Will