Path: utzoo!attcan!uunet!husc6!ukma!rutgers!rochester!pt.cs.cmu.edu!a.gp.cs.cmu.edu!koopman From: koopman@a.gp.cs.cmu.edu (Philip Koopman) Newsgroups: comp.lang.forth Subject: Re: Forth Preprocessor Summary: forth extensions don't have to cost you at run time. Message-ID: <3083@pt.cs.cmu.edu> Date: 23 Sep 88 14:35:07 GMT References: <13613@mimsy.UUCP> <3492@phri.UUCP> <23378@wlbr.EATON.COM> <1642@crete.cs.glasgow.ac.uk> Sender: netnews@pt.cs.cmu.edu Organization: Carnegie-Mellon University, CS/RI Lines: 43 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.