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.