Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!purdue!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!ukc!strath-cs!glasgow!orr
From: orr@cs.glasgow.ac.uk (Fraser Orr)
Newsgroups: comp.lang.forth
Subject: Extensible or Preprocessor
Message-ID: <1650@crete.cs.glasgow.ac.uk>
Date: 22 Sep 88 18:18:08 GMT
References: <1593@crete.cs.glasgow.ac.uk> <810002@hpmtlx.HP.COM>
Reply-To: orr%cs.glasgow.ac.uk@nss.ucl.ac.uk (Fraser Orr)
Organization: Comp Sci, Glasgow Univ, Scotland
Lines: 26

In article <810002@hpmtlx.HP.COM> adam@hpmtlx.HP.COM ($Adam Kao) writes:
>Fraser, the reason I like forth is because it's INCREMENTALLY COMPILED.
>This means I get the fast turnaround of an interactive system (think-edit-
>run vs. think-edit-compile-run) while generating code that runs almost as
>fast as compiled code.

[Reasons about exploration and fast trun around deleted,
 since they say basically the same as above ]

There is of course no reason why a preprocessed language cannot be 
incrementally compiled.  In fact no reason why it cannot be
interpreted. E.g., the equivelent of forth's ';' could take the 
preceding definition preprocess it and then make a definition.
All of these advantages need not be lost by using a preprocessor.
Thus I think your conclusion ...

>I think this and the other reasons that have already been posted are excellent
>justification for rejecting a preprocessor.
>
is unjustified.

>Adam

Regards,
===Fraser
(PS sorry I couldn't reply to your mail Adam, I couldn't  find a route)