orr@cs.glasgow.ac.uk (Fraser Orr) (09/21/88)
The discussion on the usefulness (or not) of a forth preprocessor has been blazing for quite a while now. I feel that progress toward any kind of conclusion or concordance is hidered by the discussion being a mixture of several issues. I reckon that separate discussion of these issues would be of benefit. Most of the posters have agreed that raw forth is not really sufficient but have claimed that forth gives you the ability to extend the language and environment to make the language more useful. I see the issues as follows. 1) What are the features that must be added to forth to bring it up to scratch You've heard me babbling on about this before, type checking, local variables, abstracting away from the parameter stack, record types, syntax, abstract types (i.e. types with user controlled operations) etc etc etc 2) Is it better to implement these by use of extensible language features or by using a preprocessor. I think it is much better to use a preprocessor since this puts the expense of these necessary features onto the compile stage(or definition stage - by the way when I talk about a preprocessor I would process each function as it was typed, not have a big compile stage at the end. That way the compile time is not really noticed.) instead of (in the case of the extensible approach) having this expense every time you run the program. A classic example of this is types. Some systems mark the elements on the stack with their type (e.g. PostScript), thus requiring run time type checking. This is expensive and since it gives dynamic binding, not good. Hubert Matthews suggested that these wonder forth chips should be extended to have an extra stack for this purpose (the do it in hardware approach), this certainly doesn't deal with the dynamic binding issue though and seems to be rather a waste of memory and chip space (yes I suppose forth has plenty of both to waste...) 3) Is it useful in a language/environment that is usually used by a single programmer to have these extensions standardised so that more than just that programmer can follow programs produced using these extensions. Yes it is useful to have standards, because it means that the programmer can communicate with the rest of humanity. Standards are also useful since it saves a great deal of duplicated work the world over. It is my attitude that if you can copy it why write it?! :-> I would be interested to hear your comments on the above (if you address each topic in a seperate article with subject lines like "New Features for Forth", "Extensible or Preprocesor" and "Single User Standards" then the discussion will not get all mixed up again.) I should also say that people might not agree with some of the assertions I have made in question 3 above, again I would be interested to hear your comments under the appropriate subject. Regards, ===Fraser
koopman@a.gp.cs.cmu.edu (Philip Koopman) (09/23/88)
In article <1642@crete.cs.glasgow.ac.uk>, orr@cs.glasgow.ac.uk (Fraser Orr) writes: > 1) What are the features that must be added to forth to bring it > up to scratch > > You've heard me babbling on about this before, type checking, > local variables, abstracting away from the parameter stack, > record types, syntax, abstract types (i.e. types with user > controlled operations) etc etc etc Yes, Forth needs some extensions to make it more useful. No, these aren't the kinds of extensions that are needed. Probably a much better place to start is by providing standardized subroutine libraries to avoid wheel-reinvention, not by mucking about with the characteristics of the language. Whether Forth has good language properties in the academic sense is not the issue. The issue for most Forth users is: does it solve the particular application problem quickly and inexpensively? Fraser has come up with all sorts of reasons why Forth is no good. Why then are people still using it? Why all the testimonials about Forth being the only way to solve a particular problem within budget & time constraints? Perhaps it's enough that Forth solves a certain class of problems well. Who cares if it's "pretty" if it gets the job done? (Pardon me, but that's my engineering background seeping through.) > I think it is much better to use a preprocessor since this puts > the expense of these necessary features onto the compile stage(or > definition stage - by the way when I talk about a preprocessor > I would process each function as it was typed, not have a big > compile stage at the end. That way the compile time is not > really noticed.) instead of (in the case of the extensible > approach) having this expense every time you run the program. Obviously, you haven't done a lot of Forth programming. Most Forth extensions do all their work at compile time -- not at execution time. Forth extensions act as a customized pre-processor for the task, they in general do not add a lot of run-time overhead. Phil Koopman koopman@maxwell.ece.cmu.edu Arpanet 5551 Beacon St. Pittsburgh, PA 15217 PhD student at CMU and sometime consultant to Harris Semiconductor.