Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ucbvax!ENG.SUN.COM!wmb
From: wmb@ENG.SUN.COM
Newsgroups: comp.lang.forth
Subject: Re: Essence of Forth
Message-ID: <9002210135.AA20505@jade.berkeley.edu>
Date: 20 Feb 90 20:32:32 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: wmb@ENG.SUN.COM
Organization: The Internet
Lines: 46

> [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.]

When running under an operating system, the underpinnings of both memory
allocation and file access is a call to the operating system, which is
not standard Forth.  The irreducible requirement is some set of words to
get at those system functions.  Direct system calls cannot be standard,
because then they would depend on the particular OS.  The next obvious
solution is to construct a wordset that can be efficiently implemented
on top of most operating systems, yet provide a portable interface.

That is exactly what the file and memory allocation wordsets in BASIS do.


Strings is a different story.  It is certainly possible to write just
about any string package in standard Forth (but having a good memory
allocator certainly can help the implementation).  On the other hand,
the efficiency may suffer unless one resorts to CODE words, which are
not portable.

The problem is not that I cannot write whatever string package I want.
The problem is that I should not HAVE to.  Lots of people reject Forth
because it forces them to reinvent wheels, when they would prefer to
build upon other's work, adding value in their own domain of expertise
instead of building this basic library and that basic library.

One could claim that one could simply select a string package that
somebody else has written.  True, one could, if one happened to
know about its existence and if one knew where to get a copy and
if one trusted the quality of that package.   Of course, then you
would probably have to spend some money documenting the package
and training your personnel about it.

If there is a standard package, then one can assume that competent
programmers know about it and that every worthwhile vendor implements
it and supports it, and you can depend on market pressure to ensure
its quality.

The grass roots approach works up to a certain point, and then it
gets bogged down in endless variation and uncertainty.  For some
uses, this is fine, but for large-scale commercial viability, it is
not fine.

Mitch