Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!willett!dwp From: dwp@willett.UUCP (Doug Philips) Newsgroups: comp.lang.forth Subject: Re: Why is Postscript not Forth? Message-ID: <465.UUL1.3#5129@willett.UUCP> Date: 14 Feb 90 01:39:02 GMT References: <9002121712.AA24871@jade.berkeley.edu> Organization: Latest link in the ForthNet chain. (Pgh, PA) Lines: 119 In <9002121712.AA24871@jade.berkeley.edu>, wmb@ENG.SUN.COM (Mitch Bradley) writes: > > 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. Ok. However, one of the things that Forthers sometimes claim as one of Forth's virtues is its simplicity. It seems to me that this is one place where PostScript has a simplicity that has 'out Forth-ed' Forth. You're right tho', this is a subjective call about 'Forth-like'. > 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). And you don't dare define your own way around it. ;-) but see next comment. > Then, for the strings that do exist, there are 4 different representations, > each with its own limited set of operators*. Only four? ;-) Actually, I thought this was a result of Forth's defering to the programmer to do what is right for a given situation. > So, the consistency PostScript's reverse polish PostScript syntax is not > "Forth-like", because consistency is not a hallmark of Forth. See above remark about simplicity. > * 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 Hmmm, lets not pretend the string issue exists in a vacuum. There are those of use weened on 'C' that would claim NULL terminated strings are best. I'd rather avoid religious rhetoric and stick to verifiable/demonstrable claims about real situations. > 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. Again, this is probably either due to an anti-hubris about deciding the 'one-true way' to do strings, or due to lack of 'obviously right for all circumstances' way to do strings. Did I leave out any other possibilities? > * 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. Can't wait to get my copy of BASIS11 and check it out! > 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. I can't resist replying to this... I think perhaps your characterization of 'many Forth practitioners' may be a bit skewed. I think there is an 'experts phenomina' at work here too. By 'experts phenomina' I mean that someone who has been programming in a language, or using any other mental framework for problem solving, will eventually be able to chunk large amounts of knowledge about that language/framework into 'second-nature' or 'unconcious' understandings of how to do something. Once this has happened it is often hard to get back to the process of how it happened. This is what makes expert systems hard to write, because it is hard to extract the 'why' information from the experts since they no longer 'know' at an easily accessible conscious level. What I'm saying is that perhaps at least some of the practioners you are impunging here are just looking at Forth with this perspective. [I'd be interested in continuing this discussion, but if we do we ought to make it a different subject line thread.] > (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. Hmmm... I don't know how you got the idea that Forth's ZEN-ness had anything to do with 'a way in which to live your life and interact with your fellow man and achieve spiritual salvation.'? I also don't see how you tie 'weakness is strength' in with '...to live your life...'. I can't help but think that perhaps you're over-reacting just a bit? I've always thought of the ZEN adjective, as applied to Forth, as connoting simplicity and clarity. (Although I admit, as you have pointed out, that Forth often fails at reaching those goals. I'll refrain from specific comment until I know more about Forth in general and BASIS11 in particular). Perhaps I've just not got the viewpoint to see your context. When I hear 'weakness is strength', I understand that to mean that Forth is traditionally considered 'weak' because it doesn't provide a lot of the amenities that other languages/systems do, like libraries for doing strings, or memory allocation, or... and to say that this 'weakness' is strength is to say that Forth is not cluttered up with someone else's idea of the best way to do something. 'Not cluttered' meaning both 1) an implementation free of 'junk' words and 2) a conceptual freedom from 'junk' paradigms to overcome. Then again, maybe I'm just talking out my hat. -Doug P.S. I too like Forth and would like to see it grow out of its warts. I'm just not yet sure what all the warts are or what Forth is. Hopefully by the time the *next* ANSI standard is being considered we'll have enough 'existing practice' to take the next officially condoned evolutionary step. In the meantime I'm all for experimenting with what that kind of Forth would be like, and how far it can be pushed and still be considered Forth. --- Preferred: willett!dwp@gateway.sei.cmu.edu OR ...!sei!willett!dwp Daily: ...!{uunet,nfsun}!willett!dwp [in a pinch: dwp@vega.fac.cs.cmu.edu]