Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!seismo!rochester!ritcv!cci632!rb From: rb@cci632.UUCP (Rex Ballard) Newsgroups: net.lang Subject: Extensibility (Re: RRe: What's so good about FORTH? Message-ID: <152@cci632.UUCP> Date: Mon, 30-Jun-86 13:30:36 EDT Article-I.D.: cci632.152 Posted: Mon Jun 30 13:30:36 1986 Date-Received: Wed, 2-Jul-86 04:21:03 EDT References: <201@pyuxv.UUCP> <3700003@uiucdcsp> <132@vaxb.calgary.UUCP> <813@jplgodo.UUCP> <679@ucbcad.BERKELEY.EDU> Reply-To: rb@ccird1.UUCP (Rex Ballard) Organization: CCI, Rochester Development, Rochester, NY Lines: 99 Keywords: FORTH, threaded-code Summary: difference in Mind Set. 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... > > Wayne 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 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. 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. 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. 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. Other languages are extensible. In fact there are other languages that are BETTER than forth if extensibility is required. 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. 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. 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. For example: 2 3 4 + - is equivilant to 3 4 + 2 - which in a C expression (infix) would be 4+3-2 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. 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". 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). 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.