Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!mintaka!ai-lab!zurich.ai.mit.edu!markf From: markf@zurich.ai.mit.edu (Mark Friedman) Newsgroups: comp.lang.scheme Subject: Re: standards Message-ID: Date: 30 May 91 17:46:46 GMT References: <1991May30.013756.21021@cs.umn.edu> Sender: news@ai.mit.edu Reply-To: markf@zurich.ai.mit.edu Organization: M.I.T. Artificial Intelligence Lab. Lines: 78 In-reply-to: boley@cs.umn.edu's message of 30 May 91 01:37:56 GMT In article <1991May30.013756.21021@cs.umn.edu> boley@cs.umn.edu (Daniel Boley) writes: I respectfully agree with the spirit of the letter. But as a practical matter, if portability is desired, you will have to look at what is in the actual implementations. Many leave out certain "optional" constructs, like reals, rationals, "case", bignums, ... (these are the ones I have run across). Case is not optional. The result is that I can develop code on my scheme that claims to be "standard" using only "standard" constructs, but then my friend can't run the same code on his/her scheme. I don't get it. The standard says that some things are not required. It should be obvious that portable code should not depend on those features. One solution for all those optional things is that there be some scheme library that can be loaded to add in the "optional" features. As far as I know, the only optional things in the IEEE standard are the numeric types, that is, implementations are not required to implement the whole tower. RnRS does have some non-essential syntax and procedures, but they are clearly marked, and again, portable code obviously should not depend on them. Unfortunately, adding many optional features via scheme source will require macros. But if portability is a real goal, there must be some **standard** way of adding many of the optional features so that every scheme implementation can have a common base, including most of the common optional features. At the moment, it is possible to leave out the most unexpected "optional" features, and still "adhere" to the standard. I agree that we need macros for portability, but not for standard adherence. A related point: If you want the language to be used widely by many people in many disciplines, you have no choice but to make the language big enough to handle their needs. I disagree. Implementations may need to be big, but not the standard. This has been a strong philosophical stance of the Scheme community for a long time. This follows the suggestion of a library. There would be a basic standard language, and there would be a standard set of loadable code to expand the language to adhere to an agreed-upon wider standard, in case the implementation does not have the corresponding features built in. There has been Scheme libraries for quite a while. The problem has been that until Ozan Yigit took over (de facto) none of the librarians was particularly agressive in getting code and very few people contributed any. The lack of macros hinders the usefulness of contributed code, because few people actually write portable code. They exploit their "big" implementations. This might change in the near future because there are more "small" implementations and therefore more people who have to write portable code :-) With the narrow standard that exists today (that is the standard with none of the optional features), every implementor feels free to decide how to expand the language to his/her own demands, and each one does it differently. That's exactly the point. Provide freedom to implementations while allowing the developement of portable code. -Mark -- Mark Friedman MIT Artificial Intelligence Lab 545 Technology Sq. Cambridge, Ma. 02139 markf@zurich.ai.mit.edu