Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!purdue!bouma
From: bouma@cs.purdue.EDU (William J. Bouma)
Newsgroups: comp.lang.forth
Subject: Re: Forth in C (was Re: Forth from scratch)
Message-ID: <8630@medusa.cs.purdue.edu>
Date: 13 Nov 89 21:27:57 GMT
References: <4839@sdcc6.ucsd.edu> <2570@fai.UUCP> <4969@sdcc6.ucsd.edu>
Organization: Department of Computer Science, Purdue University
Lines: 102

In article <4969@sdcc6.ucsd.edu> ir230@sdcc6.ucsd.edu (john wavrik) writes:
>
>   There are two things at issue here: the definition of "toy" and the reason 
>that an assembly language implementation is desirable for Forth. Let me deal 
>with the second issue first. 
>
>   Because Forth is close to the architecture of the host processor (and 
>includes an assembler) it does have the advantages Kurt Luoto notes (it is 
>good for projects which require machine-level access and for projects which 
>require efficiency). But it is a mistake to assume that these are the primary 
>reasons for implementing Forth in the traditional way (using a little 
>assembly language and a lot of Forth). Traditional Forth implementation is so 
>simple that it is easy to add new features to the language -- new primitives, 
>control structures, data types, etc.  What would you like:  quadruple 
>precision integers?  complex numbers as a primitive data type?  graphics?  
>strings?  local variables?  arithmetic of sets?  A construct  "IF:  COND1 
>COND2 COND3 ... DO:"  that tests for a conjunction but will stop testing as 
>soon as a condition fails?  redirection of I/O?  It is one thing to say that a 
>professional compiler writer can build these things into a language -- quite 
>another to say a language allows such things to be added by typical users. 
>
>    The ability of a USER to add to a language almost anything one could 
>conceive of is a rare attribute. It is this extraordinary degree of control 
>(rather than the use of stacks and RPN) that characterizes Forth -- and it 
>comes from the simplicity and accessibility of Forth implementation. Forth 
>(when implemented traditionally) is more than just a rather small interactive 
>stack-based language with Reverse Polish Syntax.  


    I fail to see what all this has to do with implementing forth in
    assembly language? I see no reason a forth interpreter written in
    any other language could not be made to behave identically to one
    written in assembly! You have given here no arguments to convince
    me otherwise. There are several reasons to write forth in assembly,
    speed, access to hardware, or limited memory. But ease of programming,
    as the above seems to imply, is not a valid reason.
 
    Also, I have to disagree with the rest of what was said because the
    main thing that distinguishes forth from other languages is the 
    parameter stack. Other languages (yes, even C) provide means to 
    build new data types using structures. One can build new operations
    by writing functions. A language which does not allow the user to add
    to it would not be very useful!


>    To make matters more concrete, suppose a Forth implementation lacks 
>certain primitive words involving double precision numbers (D+, D-, */, */MOD, 
>etc.), lacks a desired feature (like access to the OS timer) and has some 
>errors in the implementation of one or two primitives. A typical Forth 
>programmmer using a traditional Forth system can readily add the words (they 
>have short definitions in assembly language), provide the features, and fix 
>the bugs. 


    The thing that bothers me about this is that you seem to be implying
    that the user knows the host assembly language? If not, then what is
    the difference between having your forth core written in assembly, or
    having it written in basic? Speed!


>   How is one to characterize a Forth implementation that does not allow a 
>user the ability to add new primitives to the language?


    I wouldn't call it forth, and probably wouldn't call it a language.


>                                                        Or to tap features of 
>hardware and OS to do such simple things as adding a timer


    I'd call that a "high level" language! 8^)


>                              By imbedding Forth in another language this is 
>exactly the situation that seems to be produced. New primitives cannot be 
>added (or existing ones modified) from within the Forth environment without 
>knowledge of how the program and compiler handle register assignments and 
>stacks.


   Why not? What do registers have to do with it? If you are writing from
   "within the forth environment" you are writing forth, right? Then why
   does it matter what that forth was written in?


>   Let me emphasize again that it is not speed or the ability to do hardware 
>control applications that is the main argument for the traditional 
>implementation of Forth. It is the resulting simplicity and accessibility of 
>the implementation -- making the language malleable, allowing a user to 
>exercise a high degree of control and to add powerful features as options. 


   When is it simpler to write in assembly language? When one knows the
   assembly language. When is it more accessible to write in lisp? When
   one knows lisp. When is it simpler and more accessible to write in
   forth? I would like the answer to that to be the obvious, rather than
   when one knows forth AND knows the language/machine that forth was
   written in!

-- 
Bill <bouma@cs.purdue.edu>  ||  ...!purdue!bouma