liberte@uiucdcsb.CS.UIUC.EDU (06/20/86)
We've heard about some of the good things of Forth. I would like to turn the discussion around a bit and ask, if Forth is so good, why isn't it being used? First, one advantage I would like to expand on is the extensibility feature. Not only can you add new words to the dictionary, but you can also add new defining words. A defining word is like other words except that it is used in defining other words (including other defining words). Generally, execution of a defining word will interrupt the normal flow of execution/compilation and start adding a new word to the dictionary. When you create your own defining word, you must specify not only what to add to the dictionary when the defining word is executed (to define some new word), but you must also specify what happens when the newly defined word is executed. This is a powerful, general feature that attracted me to investigate further. I was driven to learn how to use this extensibility to go beyond the starting point of Forth's rudimentary reverse polish notation and to possibly define more familiar, powerful, higher-level-languages. Other people have done as much, but what I learned in the process killed my enthusiasm. Some of the problems: The basic lexing/parsing tool is to read the next "word" into a buffer up to a specified character, usually a space. Only one such character may be specified. Thus words are usually space separated. Yes, you may write your own lexing tool, but you have to do it in Forth. There are a few prefix or infix operators, but Forth is almost entirely postfix. This is as bad as Lisp's prefix orientation, only without the parentheses to guide you in figuring out what you are doing. You have to maintain the parameter stack manually, a trick business even for the experienced. I imagine that coding in p-code would be a similar experience. The inner interpretor discussed in other notes which evaluates the threaded code basically takes control of the operation in such a way that it prohibits you from modifying the way in which it executes. This is complicated to explain, but it prevents one from writing a stepping debugger. It has to be built in from the beginning. So you are limited to the old edit/compile/execute cycle, although you need only recompile the definitions you change. But the editors generally stink. Definitions are kept in one file of blocks, each block is 16 lines by 64 characters, space filled (so you waste the space at the end of lines unless you fill them up with comments which are needed heavily). Usually you work with one block at a time. Yes, you may write your own editor, but you have to do it with the editor provided. Memory management is stack management. You add definitions and data structures at the end of the dictionary only, and then you may "forget" everything back to some definition. That's it. Unless you do major surgery. What else? Error processing is usually left out. The primative data structures are integers reals and vectors. No strings unless you add them. No records unless you add them. Words may not be overloaded so there is a host of addition operators, for example, one for each data type with funny names like +D or +F or +A. There are hundreds of primatives to look up in the sparce documentation. The whole orientation of Forth is so space conscious at the expense of readability and maintainability that those people who get into using and developing Forth also don't seem to care about going beyond what is given. They like it as it is. So as far as I am concerned, there is almost no support for what I want(ed?) to do. Take this note as a warning of what you are getting into if you are attracted to Forth as I once was. Dan LaLiberte liberte@b.cs.uiuc.edu liberte@uiuc.csnet ihnp4!uiucdcs!liberte
philm@astroatc.UUCP (Phil Mason) (06/23/86)
In article <9100009@uiucdcsb> liberte@uiucdcsb.CS.UIUC.EDU writes: > >We've heard about some of the good things of Forth. >I would like to turn the discussion around a bit and ask, if Forth >is so good, why isn't it being used? > . . . > >Some of the problems: > >The basic lexing/parsing tool is to read the next "word" into a buffer up >to a specified character, usually a space . . . >Yes, you may write your own lexing tool, but you have to do it in Forth. To expect more of Forth's outer interpreter is to expect more of any feature of the language. Forth is simple, yet versatile. If you really want to make a new parser, fine. You don't have to do it in Forth, you can do it in assembly language. >There are a few prefix or infix operators, but Forth is almost entirely >postfix. This is as bad as Lisp's prefix orientation, only without the >parentheses to guide you in figuring out what you are doing. >You have to maintain the parameter stack manually, a trick business >even for the experienced. . . This is a very valid point, but one that can be said of many languages that are not as rigid as C or Pascal. BASIC is unmanagable in the sense of structure. Forth is flexible in the sense of parameter passing. Sure, keeping track of the stack is a pain, but the other side of the coin is that well constructed words and applications can be a pleasure to use because of the simplicity of the syntax. >The inner interpretor discussed in other notes which evaluates the >threaded code basically takes control of the operation in such a >way that it prohibits you from modifying the way in which it executes. >This is complicated to explain, but it prevents one from writing a >stepping debugger. It has to be built in from the beginning. >So you are limited to the old edit/compile/execute cycle, although >you need only recompile the definitions you change. If you want to modify the way Forth works, it is quite easy to Meta-compile a new copy with any extra bells and whistles (or necessities) that you desire. >But the editors generally stink. Definitions are kept in one file of blocks, >each block is 16 lines by 64 characters, space filled (so you waste the >space at the end of lines unless you fill them up with comments which are >needed heavily). Usually you work with one block at a time. >Yes, you may write your own editor, but you have to do it with the >editor provided. I agree. The editors do stink; however, they are a hell of a lot better than having no editor at all or having a more rigid operating system and language where a substantial effort would be required to write a new one. Editors are one of the first things that are rewritten by the owner of a Forth interpreter. Sure you have to rewrite an editor in the present editor. What do you expect? Most editors are very short, a dozen screens or so - even the screen-oriented ones. Screens (Blocks) represent the most rudimentary form of disk management. The concept of screens are, however, portable and extremely easy to implement on a new computer. Using a screen as a fundamental unit of source code chunk yields some benefits. For example, you will not find a word that is longer than a screen in length (although it is possible, it is bad style). Screens should not be packed with too much information. Come on, a little white space does wonders for any source code and comments. In this day and age of quad density disks, we have disk space to burn. Shadow documentation screens are a neat idea. Essentially every code screen has a documentation screen that is edited in parallel with the code. The shadow screen is called up automatically upon calling up a source screen for editing. >Memory management is stack management. You add definitions and data structures >at the end of the dictionary only, and then you may "forget" >everything back to some definition. That's it. Unless you do major surgery. I think you are expecting way too much of a simple system. Forth is simple, portable and versatile. Why would you want to add messy memory management to Forth? LISP really can't be used in real time situations because of garbage collection. To each his own - Forth can be hacked any way you want. If you go too far, you lose alot of the advantages of Forth. >What else? Error processing is usually left out. The primative data >structures are integers reals and vectors. No strings unless you >add them. No records unless you add them. Words may not be overloaded >so there is a host of addition operators, for example, one for each data type >with funny names like +D or +F or +A. There are hundreds of primatives >to look up in the sparce documentation. Error processing is left out so that you can put it in - if you want. Forth's data structure tools are versatile enough to add any types you desire - if you need them. The variety of operators is due to the fact that Forth has tools for every primitive data type. The names are mnemonic, much like assembly code. If one were to tag each datum on the stack with a type, every word in Forth would be much more complicated with little advantage. The sparseness of the system documentation is indicative of the grass-roots beginning of Forth. It's getting better, though. I'd rather code in Forth than assembly language, any day. >The whole orientation of Forth is so space conscious at the expense of >readability and maintainability that those people who get into using >and developing Forth also don't seem to care about going beyond what >is given. They like it as it is. So as far as I am concerned, there >is almost no support for what I want(ed?) to do. If you have ever designed a major piece of software and have tried to maintain it, you should realize that there is no substitute for good code and good documentation. Forth or any other language can be readable or unintelligable. It's your choice. I think it is a bit narrow to single out Forthers as being the font of bad style. It seems that what you wanted to do was to radically restructure Forth. If you go too far, you lose all of the simplicity, portability and versatility of Forth. You end up with a system that can not be called Forth and does not share its advantages. Try restructuring LISP or C or Pascal if you want to really run into a wall. >Take this note as a warning of what you are getting into if you >are attracted to Forth as I once was. This sentence is what I really take exception to. Why the hell do you want to warn people away from Forth? You asked too much of a very simple language and now, because of your attitude, you will dissuade others from experiencing their own journey of discovery. Maybe that person will like Forth, maybe not. You have expressed the opinion that Forth is not for you. That's fine. Please don't tell other people that Forth is a crock because you were not able to get your ideas to work with it. That is quite unfair. You were more open-minded about Forth than most. Alot of people dismiss Forth without really trying it. It is important for people to try something before abandoning it. Forth is not for everyone, but for those of you who are interested in further readings about Forth and its relationship to other pools of thought, try these books : "Starting Forth" and "Thinking Forth" by Leo Brodie. "Forth Fundamentals Volumes 1 and 2" by C. Kevin McCabe. "Forth Fundamentals" and "Starting Forth" give descriptions and introductions to Forth itself. "Thinking Forth" gives a good description of Forth and its advantages, philosophy and relationship with other languages and philosophies. "Thinking Forth" also includes chapters on applications development and good Forth style and documentation standards to follow. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kirk : Bones ? | Phil Mason, Astronautics Technical Center Bones : He's dead Jim. | Madison, Wisconsin - "Eat Cheese or Die!" - - - - - - - - - - - - - - - -| ...seismo-uwvax-astroatc!philm | I would really like to believe that my ...ihnp4-nicmad/ | employer shares all my opinions, but . . . =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
schaefer@bgsuvax.UUCP (Stephen Schaefer) (06/25/86)
``Memory management is stack management'' is a failing of the implementation of Forth, more than of the language itself. That implementation shows up most annoyingly in FORGET: it throws away everything after the word you really want to change (which could be 20 or 30 definitions deep). This is another reason you fall back into the edit/compile/execute loop, especially when debugging. -- Stephen P. Schaefer Systems Programmer schaefer@bgsu ...!cbosgd!osu-eddie!bgsuvax!schaefer
liberte@uiucdcsb.CS.UIUC.EDU (06/26/86)
Phil's response to my note was not the flame I anticipated. Thanks for being civilized, not that I expected you wouldnt be...:-) But it did reflect well the perspective of many Forth programmers. As he repeatedly pointed out, if you want something different from what is given, you can build it yourself. But my point is that you dont have much to start with. Across the board, almost every feature of Forth is very primitive compared to what I am used to, and even that is primitive compared to what I want. The one thing that attracted me was the Builds-Does extensibility. This is the only feature not found in (many) other languages. >/* Written 10:28 am Jun 23, 1986 by philm@astroatc.UUCP in uiucdcsb:net.lang.forth */ >If you want to modify the way Forth works, it is quite easy to Meta-compile >a new copy with any extra bells and whistles (or necessities) that you desire. > ... >If you go too far, you lose alot of the advantages of Forth. > ... >I'd rather code in Forth than assembly language, any day. OK, compared to assembly language, Forth is great. But I don't code in assembly language either. > ... >It seems that what you wanted to do was to radically restructure Forth. >If you go too far, you lose all of the simplicity, portability and versatility >of Forth. You end up with a system that can not be called Forth and does not >share its advantages. Try restructuring LISP or C or Pascal if you want to >really run into a wall. Yes I wanted to radically restructure Forth. I wouldnt mind trading alot of Forth's simplicity for more powerful tools. Other languages dont have the same kind of extensibility as Forth, but almost all (simple basics excluded) have a named subroutine extensibility *built in* to the language. I won't comment on the portability and versatility issues. >>Take this note as a warning of what you are getting into if you >>are attracted to Forth as I once was. >This sentence is what I really take exception to. Why the hell do you want to >warn people away from Forth? My statement was not a warning to keep away from Forth. Did I say "Dont waste your time"? You're welcome to waste your time if you want. :-) By all means, learn about Forth. It is interesting as a language. But just keep in mind what you are getting into. >Forth is not for everyone, but for those of you who are >interested in further readings about Forth and its relationship to other >pools of thought, try these books : If you are interested in how Forth works internally, you will need something like (I forget the exact title and author) "The System Programmers Guide to Fig-Forth". Most books do not get into the Builds-Does constructs either, which leads me to believe that most Forth programmes do not use it much. Dan LaLiberte liberte@b.cs.uiuc.edu liberte@uiuc.csnet ihnp4!uiucdcs!liberte
magik@chinet.UUCP (Ben Liberman) (06/27/86)
>If you are interested in how Forth works internally, you will need >something like (I forget the exact title and author) "The System >Programmers Guide to Fig-Forth". Most books do not get into the >Builds-Does constructs either, which leads me to believe that >most Forth programmes do not use it much. > > >Dan LaLiberte >liberte@b.cs.uiuc.edu >liberte@uiuc.csnet >ihnp4!uiucdcs!liberte Another excellent book is "Threaded Interpretive Languages" by Ting (?) It talks about how to write your own TIL and just how simple it is to do from scratch once you understand the pricinples involved. ---------------------- Ben Liberman ihnp4!chinet!magik or ihnp4!homebru!magik
philm@astroatc.UUCP (Phil Mason) (06/27/86)
In article <9100013@uiucdcsb> liberte@uiucdcsb.CS.UIUC.EDU writes: > >Phil's response to my note was not the flame I anticipated. >Thanks for being civilized, not that I expected you wouldnt be...:-) Civility and a good measure of tact and restraint are necessary in this forum since it relies soley on the written word. Verbal cues and body language fail dismally in this arena. >But it did reflect well the perspective of many Forth programmers. >As he repeatedly pointed out, if you want something different from >what is given, you can build it yourself. But my point is that you >dont have much to start with. Across the board, almost every feature >of Forth is very primitive compared to what I am used to, and even that >is primitive compared to what I want. The one thing that attracted >me was the Builds-Does extensibility. This is the only feature not >found in (many) other languages. Forth is indeed a bit on the primitive side. This leaves the applications writer with a simple set of simple tools to work with. Using the tools, one can create your favorite set of meta-tools to create applications. Screens come in handy by making your sources swappable and reuseable at the source level. Careful construction of each new application can yield lots of tools to use on the next project. >>I'd rather code in Forth than assembly language, any day. > >OK, compared to assembly language, Forth is great. But I don't code >in assembly language either. Forth is a good language for a lot of things. Assembly is a real pain unless you really need the speed. Forth gets you close to the machine without the excess baggage. >>It seems that what you wanted to do was to radically restructure Forth. >>If you go too far, you lose all of the simplicity, portability and versatility >>of Forth. You end up with a system that can not be called Forth and does not >>share its advantages. Try restructuring LISP or C or Pascal if you want to >>really run into a wall. > >Yes I wanted to radically restructure Forth. I wouldnt mind trading >alot of Forth's simplicity for more powerful tools. Other languages >dont have the same kind of extensibility as Forth, but almost all >(simple basics excluded) have a named subroutine extensibility *built in* >to the language. I won't comment on the portability and versatility issues. Build tools in Forth. It's alot of fun. >If you are interested in how Forth works internally, you will need >something like (I forget the exact title and author) "The System >Programmers Guide to Fig-Forth". Most books do not get into the >Builds-Does constructs either, which leads me to believe that >most Forth programmes do not use it much. Builds(Create)-Does gives you the the freedom to create new classes of words with your desired bizzare behavior. Builds(Create) describes what kind of structure you create in the dictionary and Does describes the run-time behavior of the words you create. Some Forth programmers don't seem to use them much. Too bad. They're alot of fun and quite useful. I guess my main point is that Forth is really a fun language to use and its extensibility and simplicity make it useful for a wide variety of applications. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kirk : Bones ? | Phil Mason, Astronautics Technical Center Bones : He's dead Jim. | Madison, Wisconsin - "Eat Cheese or Die!" - - - - - - - - - - - - - - - -| ...seismo-uwvax-astroatc!philm | I would really like to believe that my ...ihnp4-nicmad/ | employer shares all my opinions, but . . . =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=