Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!umich!yale!cmcl2!acf5!sabbagh From: sabbagh@acf5.NYU.EDU (sabbagh) Newsgroups: comp.lang.forth Subject: Re: (none) Message-ID: <1032@acf5.NYU.EDU> Date: 18 Jan 90 16:53:34 GMT References: <9001180238.AA28716@jade.berkeley.edu> Reply-To: sabbagh@acf5.UUCP () Organization: New York University Lines: 91 In article <9001180238.AA28716@jade.berkeley.edu> Forth Interest Group International List writes: >> >The trouble with this topic is that everybody in the whole world has >> >a different idea about what "looks" good. Everybody is "used" to something >> >from exposure to some random assembly language. >> >> I'm not sure what the fuss is about here. For years, over several >> different Forth... ... >> a specified base. My preference happens to be "H" for hex, and >> the default is decimal, but so what - the character can be any >> non-numeric you pick. > >The fuss is not about how to implement it. The fuss is about choosing >exactly one syntax so that source code will be portable between 2 >different programmers. > >> Forths that vector NUMBER make this >> especially easy, but I have never had much trouble finding >> a way to redefine low level words regardless of the implementation. >> One of the nicer features of Forth. > >On the other hand, the fact that you have felt the need to modify >all these systems to change the number input syntax argues that >there is something lacking from the "standard" number input syntax. We finally come to a very important point. ANY STANDARD IS BETTER THAN NONE AT ALL. I think this was stated a number of times in this discussion. The advantage that Forth has over other languages is that if you are not worried about portability, YOU DON'T HAVE TO FOLLOW THE STANDARD. However, every system developed must provide at least the standard. So, you say, Forth has SEVERAL standards, the most recent in current use being Forth-83. This standard, unfortunately, was not flexible enough to provide the one thing a standard is really useful for: portability. It mandated 16-bit word size, block I/O and a number of other restrictions. Result: many people wrote code that DEFEATS the standard. An excellent analogy is MS-DOS vs. Macintosh. There are many MS-DOS applications that circumvent MS-DOS, in order to provide the user the features. Result: there is no consistency between MS-DOS applications. OTOH, most Mac applications use the Toolbox, so they are globally consistent. This problem is present in Forth, but is much worse, since programs are not just a mode of communication with a computer, BUT A MODE OF COMMUNICATION BETWEEN PEOPLE. I feel that the next standard should address the following issues: 1. Word size independence. This is easy to do; use the CELL semantics. This allows users to worry about word size only when necessary. Force the stack to be the largest integer supported by the machine. 2. Standardized extensions. This is the restricted word set idea and is equivalent to the ANSI C standard library. 3. Standardize primitive data types and operators Forth NEEDS this. The primitives would include integer, float, character, and string types. They have the property that almost every other data type in a program is built up from these. The standard should include initialization of constants and variables and, for integers, different bases. I confess to be heavily influenced by C. Forth's greatest strength over C is also its greatest weakness. It allows the programmer to express the solution efficiently; an advantage. It forces the programmer to make all the decisions up front; a disadvantage. A good standard can alleviate the second, without affecting the first. Sigh...have to break out my asbestos suit now...:-) Hadil G. Sabbagh E-mail: sabbagh@csd27.nyu.edu Voice: (212) 998-3125 Snail: Courant Institute of Math. Sci. 251 Mercer St. New York,NY 10012 +===============================+ | | | ________ _______ | | \ | / ______ | | \ | / / | | \ L____/ / | | \__________/ | | | | | | Ceci n'est pas une pipe | | | +===============================+