rb@cci632.UUCP (Rex Ballard) (06/30/86)
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.
faustus@ucbcad.BERKELEY.EDU (Wayne A. Christopher) (07/01/86)
Perhaps this discussion is bothering some people, but I have another question about forth for the gurus on the subject -- the major advantage of C (as I see it) over Fortran, etc is the possibility of defining structures and abstract types. Does forth have anything comparable, or are there any forth paradigms that make this easy? Also, what sort of position does forth take in the spectrum with functional programming on one end and object-oriented programming on the other? It seems to me that (like C) forth doesn't really try to deal with this problem... Wayne
philm@astroatc.UUCP (Phil Mason) (07/02/86)
In article <770@ucbcad.BERKELEY.EDU> faustus@ucbcad.BERKELEY.EDU (Wayne A. Christopher) writes: >Perhaps this discussion is bothering some people, but I have another >question about forth for the gurus on the subject . . . This IS net.lang. This is what this news-group is for. Now if we were on net.women . . . As you were saying ... >The major >advantage of C (as I see it) over Fortran, etc is the possibility of >defining structures and abstract types. Does forth have anything >comparable, or are there any forth paradigms that make this easy? Yes, there are the Builds(Create) - Does words that can define a new class of words. The Builds(Create) words allocates the proper space and does any necessary initialization. Does describes the run-time behavior of the new word. A short time ago, a gentleman posted a 16 line Forth implementation of Pascal record structure types on net.lang.forth. You can very succinctly describe any data structure you want either from scratch with Builds(Create)- Does or a set of tools that use them. >Also, what sort of position does forth take in the spectrum with functional >programming on one end and object-oriented programming on the other? >It seems to me that (like C) forth doesn't really try to deal with this >problem... Forth philosophers point out that a guiding principle behind Forth is that Forth words should do their share of the work. In other words, the functionality of the system should be equitably broken among the component words. If I have a statement that says 'FOO BAR BAZ', each of the words is a tool, a building block to describe the semantics of the statement. If these words do their own work and function as a tool, they can be used by other words and in other "sentences" to convey additional meaning. The goal is to make an application and user-interface that looks like English and to create component words that can make new, semantically correct sentences. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 . . . =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
philm@astroatc.UUCP (Phil Mason) (07/02/86)
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 . . . =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
faustus@ucbcad.BERKELEY.EDU (Wayne A. Christopher) (07/03/86)
In article <474@astroatc.UUCP>, philm@astroatc.UUCP (Phil Mason) writes: > > 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. ... 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. I do, whenever possible. Perhaps when there is more pressure to get a product out the door than there is in a university environment, this sort of thing becomes less practical. But I find it nice to not have to re-write large pieces of code every time I need them... Wayne
mangoe@umcp-cs.UUCP (Charley Wingate) (07/08/86)
Wayne A. Christopher writes: >Perhaps this discussion is bothering some people, but I have another >question about forth for the gurus on the subject -- the major >advantage of C (as I see it) over Fortran, etc is the possibility of >defining structures and abstract types. Does forth have anything >comparable, or are there any forth paradigms that make this easy? Also, >what sort of position does forth take in the spectrum with functional >programming on one end and object-oriented programming on the other? >It seems to me that (like C) forth doesn't really try to deal with this >problem... Forth offers absolutely no protection for the user as far as data typing is concerned, so in that respect you don't get a lot of the benefits of abstract types. It does, however, support a really hierarchical structure of operators into which operators for different data types fit nicely. A disciplined programmer can therefore reap the organizational advantages of abstract types from the language. I have a question: has anyone ever built a compiling 'compile' verb? It seems to me that it would be useful to set up some new Forth words when compiling so that they produce new subroutines rather than threaded code. C. Wingate
rb@cci632.UUCP (07/12/86)
In article <770@ucbcad.BERKELEY.EDU> faustus@ucbcad.BERKELEY.EDU (Wayne A. Christopher) writes: >Perhaps this discussion is bothering some people, but I have another >question about forth for the gurus on the subject -- the major >advantage of C (as I see it) over Fortran, etc is the possibility of >defining structures and abstract types. Does forth have anything >comparable, or are there any forth paradigms that make this easy? Actually there are several variations for handling structures in forth. The simplest is to create words that access the members, and put the address of the structure (or the structure itself) on the stack. Another trick is to treat the structure as a stream and simply build the messages "on the fly". Forth tries very hard to avoid "stamp coupling" (hiding arguments in structures). Lee Forsly wrote a paper on using defining words to define defining words that is absolutely perverse. With slight changes however, it results in a very object oriented effect. I haven't played with it much, but it has interesting possibilities. The journal also proposes several cute extensions. >Also, >what sort of position does forth take in the spectrum with functional >programming on one end and object-oriented programming on the other? In "normal use", Forth is very much a functional programming style language. Neon is a Forth-like object-oriented language. OO can be added to forth quite easily (since operators are "free form", and can be re-defined). >It seems to me that (like C) forth doesn't really try to deal with this >problem... > > Wayne There are ways to implement object oriented design even in C. There is a big difference between object oriented design and object oriented languages. If you look at it sideways, UNIX device drivers are a cute example of object oriented design.
rb@cci632.UUCP (07/12/86)
In article <473@astroatc.UUCP> philm@astroatc.UUCP (Phil Mason) writes: >In article <770@ucbcad.BERKELEY.EDU> faustus@ucbcad.BERKELEY.EDU (Wayne A. Christopher) writes: >>Perhaps this discussion is bothering some people, but I have another >>question about forth for the gurus on the subject . . . > >This IS net.lang. This is what this news-group is for. Now if we were on >net.women . . . > >As you were saying ... >>The major >>advantage of C (as I see it) over Fortran, etc is the possibility of >>defining structures and abstract types. Does forth have anything >>comparable, or are there any forth paradigms that make this easy? > >Yes, there are the Builds(Create) - Does words that can define a new class >of words. The Builds(Create) words allocates the proper space and does >any necessary initialization. Does describes the run-time behavior of the >new word. A short time ago, a gentleman posted a 16 line Forth implementation >of Pascal record structure types on net.lang.forth. You can very succinctly >describe any data structure you want either from scratch with Builds(Create)- >Does or a set of tools that use them. > >>Also, what sort of position does forth take in the spectrum with functional >>programming on one end and object-oriented programming on the other? >>It seems to me that (like C) forth doesn't really try to deal with this >>problem... > If you write your various operations, then build a "class switch" word, then use the : Class builds (size) alloc does class_funtion ; you have a class which will implicitly define its own object (like new). By creating "stack constant" operators such as : Print 1 ; You can say Class object Print object And your object, of whatever type would be printed. Cute? :-).