Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!topaz!uwvax!astroatc!philm From: philm@astroatc.UUCP (Phil Mason) Newsgroups: net.lang Subject: Re: Extensibility (Re: RRe: What's so good about FORTH? Message-ID: <474@astroatc.UUCP> Date: Wed, 2-Jul-86 11:23:21 EDT Article-I.D.: astroatc.474 Posted: Wed Jul 2 11:23:21 1986 Date-Received: Thu, 3-Jul-86 06:58:50 EDT References: <201@pyuxv.UUCP> <3700003@uiucdcsp> <132@vaxb.calgary.UUCP> <813@jplgodo.UUCP> <679@ucbcad.BERKELEY.EDU> <152@cci632.UUCP> Reply-To: philm@astroatc.UUCP (Phil Mason) Organization: Astronautics ATC, Madison, WI Lines: 163 Keywords: FORTH, threaded-code In article <152@cci632.UUCP> rb@ccird1.UUCP (Rex Ballard) writes: >In article <679@ucbcad.BERKELEY.EDU> faustus@ucbcad.BERKELEY.EDU (Wayne A. Christopher) writes: >>Maybe I'm not seeing the point about "threaded" languages -- you don't see >>C programmers claiming that the major advantage of C is that you can use >>function calls to build up higher-level routines out of lower ones... Or is >>it just that since forth is the first language many micro users use after >>basic and asm, functions (or "words") seem like a really big thing... >> > >Actually, you do see part of the point. Yes C is "extensible", as is forth. >However, most C functions are not usually thought of as "extensions" to >the language. In C and other compiled languages, the goal of writing an application is NOT to write routines that act as building block tools, but to get the application out the door as fast as possible. With Forth, you can get a set of helpful tools AND get it out the door quickly. Forth's extensibility really means that its philosophy leads the designer to create useful extensions to the language itself rather than just creating routines to do one non-reusable thing. The closest thing compiled languages have that matches the concept of Forth extensibility is their source libraries. Come on, do you write a new library every time you make an new application that includes helpful tools for writing applications? NO. Of course not. >In forth, as you work up to the top of the design (because there is >no convenient forward referencing), you view most levels with the >maximum generality possible. Forth functions are intentionally used >over and over. You can quite easily add forward referencing to Forth. A common implementation is called 'DEFER'. It's simple. Forthers have been doing it for quite awhile. As for reuse, a nice set of general tools can be used thousands of times with no bad effects. If it doesn't fit, rewrite it and save it for the next time. In a compiled language, you use the primitive routines over and over again, too . . . If you think about how you design in other languages, you still do it bottom-up or in combination with top-down. How many times do you use forward referencing? >In C, it is possible, even necessary to implement "Top Down" rather >than "Bottom Up". As a result, the C programmer will frequently >write one big monster function and break little units out only as >he needs them. In Forth, you make little functions. Nothing more than 16 lines in length if you want to use good style. No monster incomprehensible functions. If you have truly thought out your design, there is no need for monster functions. >Because forth is interactive, new functions are immediately "unit tested" >at the lowest possible levels before being integrated into new functions. >In this respect, forth is also much like a "Shell" integrated into the >language. Contrast this to C where an entire system is often run through >"Make" and successively enhanced. Often little used paths or combinations >of paths will mysteriously "break". In reality, it is easier to induce >bugs in forth code, but it is also easier (and very necessary) to debug. >Once a function is written/tested/saved in Forth, it is as reliable as the >"clib.a" functions. Whether it be easier to make bugs or not, Forth is a quick, efficient software design environment. You spend most of your creative energy waiting for the compiler to finish rather than debugging the routines you couldn't afford to make a test harness for. >In the Unix/C environment, how many "Ad Hoc" functions are written in C? >I write most of mine in awk, sh, csh, or sed. In forth, an equivilent to >these "languages" can be part of the standard vocabularies. In fact, >the "editor" vocabulary is usable as a language (very handy for writing >"data entry" functions), quite similar to Emacs. Now you're talking! >Other languages are extensible. In fact there are other languages that >are BETTER than forth if extensibility is required. Not true. LISP is the closest thing. Try writing real-time, low-level code in LISP! >Hoc6 as described in the "The UNIX Programming Environment" (Kernighan/Pike) >is an attempt at a "threaded interpreter/compler" for C. Unfortunately, >there are lexical and context sensitivities which make a fully interactive >fully implemented C system difficult. If a good threaded C "interpreter" >with "definition recording" and maybe even "saving" of source to relevant >files were included in UNIX liscences, it might improve the quality, and >the environment of C. Why try to make C in Forth? There are two different philosophies at work there. Sounds like trying to write software tools in BASIC. Something LIKE C could be created. Look at a language called MAGIC-L. >Another advantage of the '79 and '83 standards is that very long function >names are supported (up to 128 bytes on most implementations). This is >primarily because the language is not limited by the typical 6 to 8 char >limit of the assembler and linker. Again, any or all of the other languages >could have this capability, and many do. There is a practical limit to name length if you want to be able to remember and write lots of code with them. >Finally, threaded languages do not rely on a single stack and "frames". >Instead it uses two separate stacks. One for "returns" and one for >parameters. This allows one to put arguments on the stack in some >really strange ways. . . . >This can be very useful for traversing complex structures. You can >put the structures on the parameter stack, an just "walk down" the >members' "print" functions for example. > >A disadvantage of this of course is that the function is now solely >responsible for type. you can get strange results by putting a constant >on the stack and "fetching" it (treating it as a pointer). If it weren't >for the ability to interactively test, real serious bugs would build up >very quickly. True, but well-structured code and careful, consistent use of the stack is a boon, not a hinderance. >What makes forth attractive is not it's incredible power as a language. >In fact anything short of assembler is more robust. What makes forth >attractive is it's definition of the "environment" available, and the >power in relation to the hardware requirements. > >To the "comple/link" programmer who first starts "teaching" a forth >machine, it's a little like riding a motorcycle after riding a bicycle. >It is a feeling of power over the machine like you can't achieve in >a "batch" environment. You are willing to "put up" with the enemia >of the language just to have the "response" with so little "effort". Forth is not anemic. If you want a more sophisticated enviroment, write one. Come on UNIX hackers, you've been rewriting environments for quite awhile. >The big lose, at first glance, is the slower execution time. This >can be overcome with Forth "compilers" which produce tight, headerless, >rommable code that executes as fast as assembler (because it IS assembler). An optimized un-adulterated threaded-code Forth can still beat a mediocre compiler. If you want the extreme, ultra-portability, high-level Forth beats them all. >Newer languages, and older ones, are taking advantage of many of the >techniques and principles introduced by Forth. Hopefully others, such >as C, will do the same. Amen. But until they appear, Think Big, Build Small, Port Everywhere - - - Control the World with Forth. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 . . . =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=