Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!nosc!ucsd!rutgers!rochester!pt.cs.cmu.edu!a.gp.cs.cmu.edu!koopman From: koopman@a.gp.cs.cmu.edu (Philip Koopman) Newsgroups: comp.lang.forth Subject: Re: Infix/Postfix notation Summary: more thoughts on the meaning of life Keywords: infix, postfix, stacks Message-ID: <2825@pt.cs.cmu.edu> Date: 29 Aug 88 16:29:17 GMT References: <2768@pt.cs.cmu.edu> <1583@crete.cs.glasgow.ac.uk> Sender: netnews@pt.cs.cmu.edu Organization: Carnegie-Mellon University, CS/RI Lines: 94 In article <1583@crete.cs.glasgow.ac.uk>, orr@cs.glasgow.ac.uk (Fraser Orr) gave details of a box drawing routine. A somewhat condensed version is: > procedure Box (String,x0,y0,x1,y1) > begin > implicit (colour, operation) > hline (x0,x1,y0)... > hline (x0,x1,y1)... > vline (x0,y0,y1)... > vline (x1,y0,y1)... > showat(x0,y0,String) > end > end > > This would allow you to vary the parameter list within > the procedure, so that different implicit params could be given. > Can anyone really, honestly deny that this syntax is MUCH > nicer, MUCH clearer, MUCH more flexible than what we currently > have in forth? I was going to write a similar routine in forth > to contrast, but the thought of dealing with a six deep stack > was too much for me!:-> Nicer, clearer? Those are judgement calls! I absolutely abhor typing in long lists of parameters. I suppose that comes from writing too many programs using FORTRAN graphics packages that are designed this way. I consider your approach to be less flexible than Forth. I do admit that it is difficult to form an objective counter-argument (I'll have to think about this one.) As a preliminary stab, I would say that implicit parameter passing is best when stringing together sequences of words to create complex functions. This creates a combinatorial explosion of special-purpose subroutines in other languages, or creates a lot of excess typing of parameter lists that don't change. I did say earlier that I too do not relish stack twiddling, and I'm trying to think up a way to get around it. A good prospect is some adaptation of the local variable schemes I have seen for use when the stack gets too deep. > Both these comments lead me to ask again, why don't you > accept the idea of programming in a language that deals with > important issues (syntax, type checking etc) that compiles > quickly into forth? And to say that most expressions are simple > thus making them clearer is not necessary is a terrible argument. > I try to keep my expressions as simple as possible for the sole > reason of making them clearer! I *do* program in lots of other languages. Languages I consider myself proficient in include FORTRAN, BASIC, C, Pascal, and Forth. Not to mention lots of flavors of assembly language and microcode. By proficient I mean that I have written single applications that have 10K to 100K or so lines of code in each language. I have lost count of the languages I have dabbled with (LISP, Snobol, etc.) The point is that I choose to program in Forth when the problem fits the application. I don't make a blind decision out of habit. (I wish some C die-hards saw things that way!) The important issues you mention are not always important to everyone. I find that the people who use Forth are not computer scientists, they are engineers. They have recognized that Forth allows them to get the job done faster and with lower hardware cost in the finished product. The features you talk about are important for multi-megabuck software projects. They don't matter much for small applications with one or two programmers in a hurry to meet a deadline, which is where Forth is at its best. I don't use Forth for applications that require text file I/O or string handling -- the hooks just aren't there in standard Forth systems. I do use Forth for control-flow-intensive applications and for non-text database applications. As an example, the functional simulator for my latest hardware design is being written in Forth, and is MUCH cleaner and simpler than an implementation in C ever could be. Of course trying to prove this is difficult, but I consider that I have enough experience to be able to tell. One of things I think Forth needs most is a standardized full-function string handling system that is well supported by the compiler (NO, this DOES NOT mean one of the several string handling word sets, it DOES mean changing the interpretter so that it knows more about string variables and text file I/O.) When this happens I expect to use Forth a lot more. By the way, I have looked at compiling standard languages into Forth. What you end up with is a Forth-implemented virtual execution machine for that language. The result is not as efficient on stack machines as writing in Forth because other languages tend to be used in different ways than people use Forth. ---> The tool colors the method. I guess I've run off at the mouth a little, but I think that these are important subject areas. Perhaps people would like to break them off into separate topics. Thanks for the discussion, keep it up! Phil Koopman koopman@maxwell.ece.cmu.edu Arpanet 5551 Beacon St. Pittsburgh, PA 15217 PhD student at CMU and sometime consultant to Harris Semiconductor.