Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!snorkelwacker!apple!amdahl!fai!kurtl
From: kurtl@fai.UUCP (Kurt Luoto)
Newsgroups: comp.lang.forth
Subject: Re: Forth in C (was Re: Forth from scratch)
Summary: Still not toys
Message-ID: <2590@fai.UUCP>
Date: 13 Nov 89 17:36:00 GMT
References: <4839@sdcc6.ucsd.edu> <2570@fai.UUCP> <4969@sdcc6.ucsd.edu>
Reply-To: kurtl@fai.fai.com (Kurt Luoto)
Organization: Fujitsu America, Inc
Lines: 68

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.  [...]
>
> [...]  To call something "toy" does not mean that it is not useful -- it 
>means that, in comparison to a non-toy version, it lacks both important 
>characteristics and the means for obtaining them. (Thus a soap-box racer is a 
>"toy" car, but a child is not a "toy" adult).    [...]

I'll accept this as a working definition of a "toy" language implementation.

>   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. 
>
>   One of my differences of opinion with my friends who speak Forth as a 
>second language is how to best introduce Forth to speakers of their first 
>language. Their idea is to package Forth in a form that natives will find 
>familiar and comfortable (even if it means giving them the "look and feel" 
>without some of the substance). My idea is to confront new people with a 
>version of Forth that challenges rather than supports pre-conceived notions 
>about programming languages. I want them to meet Forth on its own terms. 
>
>                                                  John J Wavrik 

As one who learned Forth long before learning C, I agree that it is well
worth the time invested for a programmer in any language to learn Forth
from a traditional implementation.  And I agree that Forth's simplicity,
malleability, and extensibility are some of its essential qualities. I'm
still not convinced that a C-implementation of Forth necessarily abrogates
these qualities.

In the case study from my last posting, I had to consider C to be the
practical replacement for assembly language.  In the actual case, this was
imposed by the system's vendor.  Some users might even prefer to
use C instead of a machine's assembly languagea.  Reasons might include
    
    -- portability
    -- lack of vendor supplied assembly support
    -- easy to add in existing C code as Forth primitives
    -- familiarity

Forth programmers (users) may still add new functionality (control structures,
double precision or floating point packages, etc) by writing their code
in terms of high-level Forth words.  Of course, these implementations
will usually be less efficient.  For users who are familiar with C,
there is no problem extending or modifying a C-implementation of Forth
by adding new primitives at the C-language level.  

Now adding new Forth primitives at the C-language level is usually not done
(if not impossible) during an interactive session.  The new primitives may
be viewed as "second-class citizens" among Forth words, since their imple-
mentation is in the C source rather than in the Forth source, and adding
them requires recompiling the Forth interpreter.

So, are C implementations of Forth simple, malleable and extensible?  Yes.
Can low-level primitives be added to a C-Forth implementation as easily
as in a traditional implementation?  No, C implementations are a tad more
cumbersome.  Does this additional difficulty mean C-implementations of
Forth are only toy implementations?  I suppose this is where our
difference of opinion lies.
-- 

----------------
Kurt W. Luoto     kurtl@fai.com   or   ...!sun!fai!kurtl