Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!willett!dwp
From: dwp@willett.UUCP (Doug Philips)
Newsgroups: comp.lang.forth
Subject: Re: Essence of Forth
Message-ID: <512.UUL1.3#5129@willett.UUCP>
Date: 19 Feb 90 03:41:44 GMT
References: <7516@sdcc6.ucsd.edu>
Organization: Latest link in the ForthNet chain.  (Pgh, PA)
Lines: 96

In <7516@sdcc6.ucsd.edu>, ir230@sdcc6.ucsd.edu (john wavrik) writes:
> [Mitch Bradley refutes Forth's 'write your own' defense for its lack of
>  string package(s).]
>    This may be a significant breakthrough in rather protracted exchanges. 
> It indicates a major misunderstanding of what I had always assumed was a
> well-understood point.
> 
>    The issue is NOT that Forth programmers do not want features -- the 
> issue is how features should be provided and whether they should be built 
> in or not. 
Yes!  Yes!  Yes!

>    The most significant feature of traditionally implemented Forth is that
> 
> F1)  the *user* has access to the implementation in a way that in most 
>      languages is reserved to the specialists who implemented the 
>      language.
> F2)  the implementation is simple enough for the *user* to make use of 
>      the access.
> F3)  the "compiler" is extensible -- so that features that would normally
>      have to be incorporated into an (inaccessible) compiler can be 
>      introduced as additions by the *user*.
Ok, but does this make commercial Forth's that don't provide source and/or
capability for metacompilation not Forth?

> There are several rather enormous benefits to this:
> B1)  The user only needs to incorporate language features that are 
>      actually needed.
> B2)  The user can select from a variety of variants of a feature to 
>      choose the one best suited for an application (this particularly
>      is important for memory allocation schemes, string packages, etc.
>      where there are definite tradeoffs between extent, size, execution
>      speed, etc.)
> B3)  The user can modify a package implementing a feature to suit his 
>      needs.
> 
> [Please note (to Doug Philips and others) that I am talking about access 
> to the *implementation* not just to the *hardware*] 
Yes, I hear you.  I strongly agree with all of this.

> Forth standards should define a nucleus capable of supporting string
> packages, memory allocation schemes, etc. as portable add-ons. The
> nature of Forth makes this feasible -- and the definition of the nucleus
> should be powerful enough to support it. This, rather than quibbles about
> whether 1 or -1 should be used for TRUE, is my main concern with the ANSI
> effort. It simply does not answer to say that the ANSI team has spent 
> hours of effort building in the features that people most seem to want. 
> The real question is whether it is spending hours of effort to make sure 
> that the nucleus of the language can (as it has in the past) accept these 
> features as portable additions. 
But questions of TRUE/FALSE and representation cut to the heart of
portability.  Perhaps what X3J14 should do is *not* define TRUE/FALSE
except to say that they are returned by the relational operators (and what
ever else) and are consumed by conditionals.  That is the kind of thing
which makes portability easier.  It is also anti-Forth's-grab-the-bits-and-
run-like-hell-and-screw-portability-attitude.

> I will, like many others, buy optimized and debugged tool packages -- but
> when it comes to distributing work that I have done, I'd like to know 
> that the power of the core language has been retained -- that what I
> have done (on the level of difficulty of some of these tool packages) in 
> XYZ-Forth will also run on ABC-Forth. This, rather pragmatically (or "ad 
> hoc") is my bottom line.
And also mine.  I don't have the luxury of working in Forth professionaly.
If I'm going to putz about on my own hobby stuff, I'd like to be able to
make it available to other Forthers.  I hope that there is some chance of
that after X3J14 is done.

>    NAME ME THE FORTH VENDOR WHO WILL BE THE BORLAND OF FORTH.
>    
>    Failing that, we can standardize Forth to the extent that a package
>    written for one vendor's Forth will run on any other vendor's Forth.
>    In this way, a (second party) author of a package (who deserves a just 
>    reward for the time it takes to write a professional optimized and 
>    debugged package) will be assured of adequate compensation. 
But you said in another posting that noone will ever get rich off of
Forth. (and implied it was a good thing).  Therefore there will never
be a Forth vendor who will be the Borland of Forth.  Maybe one of the
ZEN, PYGMY, FPC, etc will make it big, but they aren't going to be commercial
successes.

> Forth should be a relatively easy language to standardize -- the kernel
> needed to support the features we are talking about is relatively small. 
> That's all we need to agree on.
> 
> [Note to Mitch Bradley:  If your memory allocation package, file package,
> string package (do you have one?), etc. cannot be written in the Standard
> core vocabulary, then pester people about the core. In return, I'll 
> grant that a floating point package must be an Extension.]
Here here!!!  (As soon as I get BASIS11 I'll join in the pestering!)

	-Doug

---
Preferred: willett!dwp@gateway.sei.cmu.edu OR ...!sei!willett!dwp
Daily: ...!{uunet,nfsun}!willett!dwp   [in a pinch: dwp@vega.fac.cs.cmu.edu]