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)