Path: utzoo!attcan!sobmips!uunet!zephyr.ens.tek.com!tekcrl!tekgvs!toma From: toma@tekgvs.LABS.TEK.COM (Tom Almy) Newsgroups: comp.lang.forth Subject: Re: Forth in C (was Re: Forth from scratch) Message-ID: <6370@tekgvs.LABS.TEK.COM> Date: 16 Nov 89 17:02:20 GMT References: <4839@sdcc6.ucsd.edu> <2570@fai.UUCP> <4969@sdcc6.ucsd.edu> <8630@medusa.cs.purdue.edu> <21215@uflorida.cis.ufl.EDU> <8637@medusa.cs.purdue.edu> <930@acf5.NYU.EDU> Reply-To: toma@tekgvs.LABS.TEK.COM (Tom Almy) Organization: Tektronix, Inc., Beaverton, OR. Lines: 74 In article <930@acf5.NYU.EDU> sabbagh@acf5.UUCP () writes: >In article <8637@medusa.cs.purdue.edu> bouma@cs.purdue.EDU (William J. Bouma) writes: >> [stuff deleted] >> Forgetting about C, what makes forth different from common-lisp? In >> CL one has an interpreter, and can create new control structures on >> a whim. Further, they look exactly like the rest of the language, >> just as they do in forth. Forth is definitely not unique as a >> language in being extensible. > >The _major_ difference between forth and Common Lisp, from a language >design point of view, is that Forth has a parameter stack and LISP does >not (so I seem to agree with you). In LISP terms, this implies that >the arguments to a procedure are evaluated _before_ the procedure is >evaluated; in LISP the procedure definition (i.e., def vs. defun vs. >ndefun, etc.) determines the evaluation its arguments. In Common Lisp, there are a handfull (good analogy?) of special forms that the evaluator knows about. All other functions get their arguments evaluated, just like Forth. Common Lisp macros (defmacro) get their arguments unevaluated, but macros execute at compile time (when the lisp compiler is used) and may be executed at compile time (execution of defun) or runtime in uncompiled functions. Macros have no real equivalent in Forth, although immediate words come close. The implementation of the Lisp interpreter can certainly use a parameter stack to hold the evaluated arguments of pending functions. I have seen implementations that do this. Of course, the parameter stack is not user accessable, as it is in Forth. I view the major difference between Forth and (Common or any other) Lisp is that in Lisp program and data have the same representation, while Forth takes the traditional approach of treating them separately. In that respect, PostScript has more in common with Lisp than Forth because you treat blocks of code as data. If Forth treated code as data, a much purer postfix function implementation would be possible. Imagine that the words { and } delimit a code literal. This would mean that: { 3 4 + . } would leave the address of threaded code block performing "3 4 + ." on the stack. If we were to then execute EXECUTE, "7" would be printed. Now lets define a new conditional "IF" statement in terms of traditional Forth operation: : POSTFIX_IF ( boolean_expression false_code true_code -- ) ROT IF NIP ELSE DROP THEN EXECUTE ; Then we could say: 4 3 > { ." Not greater" } { ." Greater" } POSTFIX_IF which would bear a strong similarity to Common Lisp: (IF (> 4 3) (princ "Greater") (princ "Not greater")) (BTW, IF is one of the special forms in Common Lisp) >To add to the "Forth written in C debate" I wish to point out that, >in UNIX, it is not _possible_ to write Forth (in either C _or_ >assembler !!!) that can allow the user to write definitions in the >native machine language (ie.e., assembler). Not true! I modified the PDP-11 fig-Forth to run under PDP-11 Unix, and have a copy of Kit Peak Unix (for the VAX), both allowing CODE words. I also brought up several 68000 Forths under Unix. There may be hardware constraints on specific machines coupled with poor Unix implentation decisions that would make it impossible, but it is not too likely -- if the implementation rules out Forth it is also ruling out Lisp! Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply