Path: utzoo!attcan!uunet!mailrus!tut.cis.ohio-state.edu!ucbvax!ENG.SUN.COM!wmb From: wmb@ENG.SUN.COM (Mitch Bradley) Newsgroups: comp.lang.forth Subject: Re: Why is Postscript not Forth? Message-ID: <9002121712.AA24871@jade.berkeley.edu> Date: 12 Feb 90 07:44:36 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Mitch Bradley Organization: The Internet Lines: 73 > Is PostScript's post-fix-"mania" more Forth-like than Forth? No. It is more consistent than Forth, and more post-fix than Forth, but not more "Forth-like". Obviously, this depends on a subjective judgement of what "Forth-like" means. I claim that "Forth-like" means "ad-hoc". Forth is rarely consistent about anything. The naming is inconsistent, the syntax is reverse polish except when it isn't, there are 4 different kinds of strings, there are some obvious comparison operators that just happen to be missing. Forth has great ideas at the bottom, and then at some point, implementors and designers got lazy and punted. Forth starts out being postfix, but then rather than deal with the issues of strings, Forth uses look-ahead syntax to try to make the issue of string allocation and representation go away (Surprise! The issue doesn't go away, it just gets deferred to later, and in the meantime, there are obvious things that you can't do with string look-ahead defining words). Then, for the strings that do exist, there are 4 different representations, each with its own limited set of operators*. Forth can't even make up its mind about the syntax of a double number. Even worse, the commonly-used, albeit non-standard, double number syntax precludes the obvious syntax for floating point numbers. So, the consistency PostScript's reverse polish PostScript syntax is not "Forth-like", because consistency is not a hallmark of Forth. * The 4 kinds of strings, and some of their operators: 1) "adr len" Address and length of array of bytes. This is the best representation. Example operator: TYPE 2) "counted string" Address of an array of from 0 to 256 bytes, the first of which is the count of the remaining data bytes. Operators: WORD , COUNT , FIND 3) "blank delimited string" Address of an array of bytes, the end of which is denoted by a space character. Operator: CONVERT 4) "name field" - Sort of like a counted string except that the count byte has the (hex) 80 bit set, and the 40 bit and 20 bit are used as flags. Also, the count may not be right; you have to look for another 80 bit set in order to find the end of the string. Operator: .ID (Okay, I know this isn't part of the standard, but it is widespread). No wonder Forth doesn't have a good standard string package; nobody can figure out which string representation to use. Besides which, the lack of dynamic memory allocation facilities* makes it pretty hard to figure out where to put them. * Memory allocation problem update: my memory allocation proposal passed at the last ANS Forth meeting! So Forth will have memory allocation one of these days when ANS Forth becomes a reality. More on this later. Mitch P.S. Lest you all get the wrong idea, I actually like Forth, and I program in it almost exclusively, entirely by choice. I would very much like for Forth to succeed, and that is why I rail against its flaws. I want the language to evolve and for the flaws to be fixed. The sad truth is that many Forth practitioners would rather pretend that the flaws are virtues and justify them or sweep them under the rug, rather than fix them. (BTW, I am pretty sick of all this "Zen philosophy" nonsense (weakness is strength, dah-dah, dah-dah) regarding Forth; we are talking about a programming language that deals with physically real hardware, whose success or failure is ultimately determined by economics, measured in real money. We are not talking about a way in which to live your life and interact with your fellow man and achieve spiritual salvation.)