[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

*To*: a.watson@xxxxxxxxxxxxxxxx, will@xxxxxxxxxxx*Subject*: Re: arithmetic issues*From*: William D Clinger <will@xxxxxxxxxxx>*Date*: Thu, 19 Jan 2006 23:06:44 -0500*Cc*: srfi-77@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx

I apologize if this shows up twice. I thought I had sent it to srfi-77@xxxxxxxxxxxxxxxxx, but it hasn't shown up yet so I probably omitted that email address. Dr Alan Watson wrote: > Would it be correct to say that you want the base language to include > all of the tools necessary for building a "full" Scheme? Yes, that happens to be my personal preference, but I don't want to argue for that except in the case of arithmetic. Arithmetic is an important part of any programming language, and has a huge impact on portability, reliability, and performance. It is also hard to get arithmetic literals and i/o right unless the base language provides adequate primitives. > Therefore, > since you suspect that R6RS will not mandate the full tower, you want > the base language to provide the primitives to implement the full tower. It's more complicated than that. I don't know what will happen with the R6RS. I hope it will mandate the full tower. Even if it does, many implementors will still need help from a portable implementation of the tower; otherwise they may ignore the R6RS, or give up on implementing Scheme altogether. While it is true that the primitives assumed by a semi-portable implementation do not have to be required by the R6RS, those primitives will be so close to the fixnum and flonum operations that several implementations already provide that it would be silly not to improve portability further by standardizing those operations. > Okay, that's reasonable and consistent. But where does it end? A "full" > Scheme should have some kind of string ports; should the base language > expose the reader suffiently to allow these to be implemented? Ideally, yes. The i/o SRFIs seem to be making progress in that direction. > A full Scheme should have vector-map, but in many > implementations, this cannot be implemented efficiently > in Scheme; should it be part of the base language? In my opinion, efficiency is an argument for putting something into the base language if there is some fundamental reason why that thing cannot be implemented efficiently in terms of the rest of the base language. Efficiency is not an argument for putting vector-map into the base language, because vector-map can be implemented efficiently in Scheme. If some system has performance problems that would cause vector-map to be slow if implemented in Scheme, then that particular system is free to implement vector-map in some other language. As language designers, it would be silly for us to become overly concerned about the efficiency of programs that run in gratuitously slow systems. If the users of those systems were seriously concerned about efficiency, they would be using a more efficient system. > SRFI-77 is fine. However, in your email you suggested that requiring > "only the fixnum/flonum foundation" in the base language was attractive. > I think the minimum you have to include is exact integers "large enough > to index any list, string, or vector that can be created" along with > arithmetic operations on these exact integers. Do you disagree? Yes. SRFI-77 says "We assume that Section 6.2.3 ("Implementation restrictions") of R5RS remains essentially as it stands." In particular, R5RS section 6.2.3 already says "An implementation of Scheme must support exact integers throughout the range of numbers that may be used for indexes of lists, vectors, and strings or that may result from computing the length of a list, vector, or string. The length, vector-length, and string-length procedures must return an exact integer, and it is an error to use anything but an exact integer as an index." When I say that requiring only the fixnum/flonum foundation is an attractive option for R6RS, second only to requiring the full tower, I certainly do not mean to imply that systems would be forbidden to support numbers that are neither fixnum nor flonum. In particular, I do not mean to suggest dropping the part of R5RS section 6.2.3 I quoted above. > Let's consider a programmer that needs to use the full tower and three > implementions: > > (a) One that supports the full tower natively. > > (b) One that supports only fixnums and flonums natively, but supports > SRFI-77 and uses your code. > > (c) One that supports only fixnums and flonums natively, does not > support SRFI-77, but does have generic R5RS arithmetic. The programmer > can then (define fx+ +), etc., and use your code. > > Can a program distinguish (a) and (b)? Should it be able to distinguish > (a) and (b)? How? No, apart from whatever incantation may be involved in activating SRFI-77 for system (b). No. No way, apart from the need to incant whatever incantation may be involved in activating SRFI-77 for system (b). > Are (b) and (c) different except in terms of efficiency? They don't even have to be different in terms of efficiency. In most of today's most efficient implementations of Scheme, all but the fixnum/flonum base is written in Scheme. > That is, are > the fixnum and flonum parts of SRFI-77 anything more than the > specification of the interface of your code with a Scheme implementation? Yes. Many Scheme programs, e.g. the nucleic benchmark, use type-specific fixnum and flonum operations. Many implementations of Scheme support such things, with relatively minor differences in semantics and naming. When such extensions are so widely supported and used, they become candidates for standardization. Will

**Follow-Ups**:**Re: arithmetic issues***From:*Alan Watson

- Prev by Date:
**Re: arithmetic issues** - Next by Date:
**Re: arithmetic issues** - Previous by thread:
**Re: arithmetic issues** - Next by thread:
**Re: arithmetic issues** - Index(es):