Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!purdue!bouma
From: bouma@cs.purdue.EDU (William J. Bouma)
Newsgroups: comp.lang.forth
Subject: Re: Forth from scratch
Summary: fun for the whole family
Message-ID: <8467@medusa.cs.purdue.edu>
Date: 30 Oct 89 20:42:28 GMT
References: <4826@sdcc6.ucsd.edu>
Organization: Department of Computer Science, Purdue University
Lines: 41

In article <4826@sdcc6.ucsd.edu> ir230@sdcc6.ucsd.edu (john wavrik) writes:
>
>Missing in this discussion is the fact that most of Forth is written in Forth.

     No, that is what the entire discussion has been about! I suggested
     that it is probably not a good idea to bring forth up from the
     minimal set of words from which this is possible.

>The idea that this results in systems which are slow and inefficient is not 
>correct. Most Forth systems include the same level of nesting as if they were 

     The point is that the minimalist implementation will be slower and
     less efficient. Also there may be words that are easier coded in the
     host assembly language than in the minimal forth set. Thus from both
     a user and an implementor viewpoint, I see no practical reason to
     implement such. If you are doing it for fun or educational purpose,
     fine.

>With regard to implementing Forth using another language: I recently had a 
>chance to examine a Forth system which is written in 'C' (which some think is 
>a "friendly language"). As it turns out, there are some surprising defects in 
>this approach. This particular Forth system happened to be missing some 
>commands and had a few others incorrectly implemented. This would be no 

     You are drawing some large unfounded conclusions here. You have one
     example of forth written poorly in C and from that you determine
     that forth cannot be written well in C! I have written forth in 6502
     assembly, and in C. I think my C version is quite nice, and it is
     portable.  But if I were to write forth for a particular architecture,
     I would do it just as you suggest, in assembler. That way one can 
     optimize the crap out of it. 

>successors to be able to begin from where we left off. We need Lee Brotzman to 
>remind us that we understand Forth because we have seen how to bring it up 
>from scratch -- and that the new generation can benefit from this exercise. 

     Yes. I do not wish to discourage any one from learning by doing. But
     I still see no reason to implement from a minimal set of primitives.
     Well, perhaps if there were a RISC-FORTH chip.
-- 
Bill <bouma@cs.purdue.edu>  ||  ...!purdue!bouma