gamber@cosmo.UUCP (Johannes Teich) (01/03/90)
In article <5846@sdcc6.ucsd.edu> ir230@sdcc6.ucsd.edu (john wavrik) writes: > Forth deserves to be taken seriously as a programming language not > because of its similarities to conventional languages, but because of > its differences. The role Forth is destined to play in history will > depend upon the ratio of statesmen to politicians in the Forth > community. But in any case it will depend upon exploiting the unique > characteristics of Forth. The world already has 'C'. It doesn't need a > Reverse Polish version of 'C'. Thank you, John, I fully agree. I wish Forth to be a bit more popular, and I think about how to make Forth a bit more handy for newcomers, but I cannot see any sense in making Forth look like other languages. > In Forth it is probably more significant that IF and THEN can be > defined by: > > : IF COMPILE ?BRANCH HERE 0 , ; IMMEDIATE > : THEN HERE SWAP ! ; IMMEDIATE > > than it is that Forth uses a stack and Reverse Polish syntax. The idea of a parameter stack is simply obvious and it could easily be managed underhand by any compiler for any language. As for the syntax, my opinion is slightly different to yours. > In keeping with an underlying philosophy of simplicity, Forth uses a > syntax that needs no parsing. The syntax follows the semantics which > equips each word with an action which is carried out when the word is > encountered. That is the reason why I don't call it a 'syntax'. It is just a sequence of instructions. (The word { + } should be spelled 'add', not 'plus'.) > Reverse Polish Syntax is probably neither more nor less aesthetic or > expressive than the syntax of conventional languages. When the > language is viewed in terms of the unifying "semantics of action" the > syntax becomes natural. You call it 'natural syntax', but I think we have touched a tender spot. Forth gives us more freedom than most other languages, so we hesitate to confess that the syntax is an exception to this rule. I'm watching this newsgroup for 18 months now (please increment your readers counter), and I remember the articles of Fraser Orr (Dublin) who claimed the usage of a Forth pre-compiler. (I also remember his excellent rhetoric. What has become of him?) Fraser's ideas were heavily attacked, and I also see that a pre-compiler in Fraser's sense would corrupt Forth in some way. But Fraser recognized that there is some discrepancy with Forth's syntax which results from the absence of one link in the chain. Pre-compilation means slower overall compilation. I think that is not as important as it is said to be. I don't see much need for repeated compilation of big programs. There could be a linker or an intelligent patcher or at least one-pass pre-compilation for the unchanged parts. There is no risk to lose track of what is going on at the 'real Forth level'. The interpreter's ability to optionally accept prefix or infix expressions would by no means hide the Forth level from the programmer. On the contrary, It could show the result of the conversion instantly and enhance understanding. The conversion should not be done at run time, as in Fifth. (I'm concerned with embedded systems. :-)) Please note that I do not try to modify Forth. What I claim is just to remove a few restrictions. (I confess, though, that I hate Forth's assembler syntax, and I'm fond of F-PC's _optional_ possibilities.) John, you recently advocated blocks & screens. In my opinion small definitions are a virtue, and I definitely want the possibility to use blocks, but I don't like to be restricted to them. Forth systems are simple & poor or comfortable & cumbersome. I think there is a third possibility: keep the kernel simple and add features as an addendum, without making the system fat. (I dislike fat systems.) For example, use inline headers for didactic convenience, or collect them into a separate segment as needed, at run time, just by keystroke. It is easier to understand the simple version plus the modification than the more complex version from the very start. In this regard I think that some sort of _optional_ pre-compiler (or pre-interpreter) would make additional features possible without abandoning any of the precious ones, especially simplicity. (Noticed the 'plus' above? :-)) I want Forth to be a tool that does 'everything' I need, and it comes rather close to this aim. I dislike that a few useful things should be impossible. And I dislike to not being able to refute some of the reproaches against Forth. cu Johannes Teich (gamber@cosmo.uucp) Murnau, FR Germany PS: Although I have to read a lot of English stuff, I am quite untrained to write in English, and I'm lost without my Langenscheidt. I apologize.