NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/forth/4015

Text File | 1993-01-27 | 10.7 KB | 256 lines

Newsgroups: comp.lang.forth
Path: sparky!uunet!starnine!mikeh
From: [e-mail] (Mike Haas)
Subject: Re: Documenting
Message-ID: <[e-mail]>
Sender: [e-mail] (Mike Haas)
Date: Thu, 28 Jan 1993 03:41:34 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: StarNine Technologies, Inc.
Lines: 244

In article <[e-mail]> [e-mail] (Bernd Paysan) writes:
>
>me>It hosts editors, the Forth compiler
>me>(and sometimes other compilers like Forth cross compilers or tiny Pascal
>me>or tiny Basic and so on).
>
>MH>Only Forth code is "hosted".  Forth is not an operating system.
>
>Forth + tiny Basic HOSTS basic. You can do SAVESYSTEM or save tiny basic
>as an binary application. Many operating systems hosts only native code.
>You can't call this: "Only native code is hosted". As soon as you host
>native code (it doesn't matter if it's the native code of the real
>machine or of any virtual machine), you host everything. My Forth hosts
>native code - so it hosts everything.

I don't know Tiny Basic, but I stand by my statement that Forth
only runs Forth code.  You may be able to support some subset of BASIC
but it has never occured that a Forth supported all of Basic or any
other language.

Forth is a hacker's dream which allows a tremendous amount of low-level
control of the hardware it runs on.  It is in no way a general-purpose
environment designed to support the widest possible range of applications
in an easy, convienient manner.

It provides no memory management above and beyond the simplistic
dictionary model, and it's standard I/O services it has to
offer are next to nil.  Device-independance is almost an
unknown concept in Forth; standard Forth only includes 2
devices (a console & a disk) without any standard means
of expanding the capabilities.

It offers no industry-standard way of managing basic text, much
less graphics objects, sound objects, animation objects.

I will admit that Forth can be made to do almost anything, but
once you've added that to a particular Forth, there will be no
other applications that operate under your "system".


>
>me>Some Forths even have ways to save applications
>me>as binary and reload them very fast (i.e. my bigFORTH).

Again, only Forth code.  Operating systems are language-independant.

>These Forths even
>me>provide something an Unix would call "Shared Libraries". A host of Forths
>me>provide multiuser abilities.

These are not necessary for an operating system, many have existed
without libraries or multitasking.  There are even UNIX environments
which are single-user.



>
>MH>It is still a Forth-only environment... NOT an operating system.
>
>Stop with this. Repeating it makes it not more true. You can load Tiny
>Pascal (I didn't port it, so you have actually some work to do), and then
>you can compile pascal programs and save them as binaries.

You can support a subset of the pascal syntax.  That does not mean
you are compiling Pascal programs and it doesn't mean Forth is an
operating system.

When you can leave off the "tiny" in those statements, and start
fully supporting other languages and applications, you will
have the rudiments of an operating system.

Forth is no more an operating system than any other interactive
programming language.  After all, that's what it is, an interactive
programming language.  And not even a very good general-purpose
one at that.


>You can start
>them up, they will link at load time (just as MS Windows' dynamic linking)
>and they will run. The parameter passing to system routines is a bit
>different from other Pascal compilers, but that's not the point. The
>feature of saving part of the application as binary and reload it later is
>not uniq to my bigFORTH. To the common definition, bigFORTH is just as
>much an operating system as Unix. Unix is NOT a C-only OS, although you
>have to use much of the C environment to start up any program (either C
>hosted or with the C linker /bin/ld linked).

The programs your 'bigForth' runs were all compiled with your 'bigForth'
compiler.  There are Forth's that were written in other languages
but that doesn't make that original language an operating system.
In fact, such Forth's can easily support the entire Forth syntax,
and does not need a 'tiny' pre-pended to it's name at all.

And to correct your statements about Unix... A non-C program can run
under Unix without C entering the picture at all.  That program
will probably have to access Unix shared-libraries to accomplish
I/O and the like, but that shared library may or may not have
been written in C.

>
>Things from Unix missing in bigFORTH: Own file system (there is only a
>file interface - but NFS is only an interface, too), no virtual memory
>management and some task and network i/o features aren't implemented.
>That's not the point. There is even a true NFS from Ewald Rieger who
>ports bigFORTH to his 68k microcontroller. bigFORTH boots from any
>sequential source, ROM or file, as you like it.

Whatever you bring your Forth or any other Forth up on, however it boots,
whatever it does, it myopically only supports compiled Forth code.

At the very best, it might be called a Forth operating system.  But
still, it's only an interactive programming language.

I feel strongly about this because it's one of the reasons Forth is
so strongly rejected by professionals who KNOW operating systems,
other languages, real-world uses for computers.  Loud
claims that Forth is an operating system is dismissed as so
much hype, and wisely so.

In my mind, the Forth community needs to spend more time figuring out how
to get Forth to LIVE EASILY under real existing operating systems.
Throw out blocks would be a good start.  Instead, Forthers commonly
blast C and other languages (all of which are profoundly more
successful that Forth) and spout off hype like "Forth is an operating
system unto itself!  It's better than any garbage anywhere!..."
on and on ad nauseum.

All of it turns away non-Forthers.

>
>The nonexistence of C compilers or so for bigFORTH has it's reason because
>bigFORTH isn't a very widespread OS and none of my user needs C programs
>hosted by bigFORTH :-).

Without even a file system, you could not produce a C compiler
in your Forth.  You would need libraries, a linker, make facility...
Of course, you could run under a real operating system to
provide these things, but that's sort of self-defeating to your
argument.


>
>MH>Just go the next logical step and throw away the BLOCK layer.  There's
>MH>no reason for it on file-based platforms, and it's continuance
>MH>hurts Forth.
>
>I have some applications using the BLOCK layer, including the ability to
>read stream files. If I cut out the BLOCK layer, no file interface will
>work.

Not true.  JForth completely interfaces with the native AmigaOS,
and it's vector for BLOCK is not even initialized.  That doesn't
happen until someone compiles in the BLOCK code (which I
don't think any of my users do).

>BLOCKs are the right primitive to implement any sort of disk I/O.

No, under a normal OS, it's primitives are the right ones, and
there is no reason to implement BLOCK because:

   1. Many disk ops read/write MUCH less than 1024 bytes.
   2. OS's provide their own block-style buffering and usually
      in chunks less than 1024 bytes.

>And I never will cut out the primitive under my block layer: It's part of
>my memory management that allows to read arbitrary parts of a file as
>purgeable memory block.

Now THAT's the kind of service an operating system provides.  And you're
taking advantage of it in your Forth.

>The block layer in between are two one-liners.
>
>Some of my files are quite large (the kernal i.e.). I don't want to wait
>seconds or more to edit one line in a file. I like structuring programs
>into screens - I do so even in stream files. I have a nice editor allowing
>both screen- and streamfiles. I think it's a matter of taste and my users
>have different tastes. The newer Forth users tend to use stream files, the
>elder stay with screen files. I don't want to reduce my market by throwing
>things out many users use and like. The market is small enough.

And it will stay that way.

>
>MH>It not only saves a tremendous amount of disk space over blocks, but
>MH>is still in a format that is interpretable...you don't have to
>MH>PKUNZIP it first.
>
>I've a 50 MB hard disk. du F:\bigforth gives about 5 MB. This is not
>tremendous - one third of this are binaries, GEM resources, dupes and
>old projects. Forth sources are so compact, if in screens or streams,
>wasting 50% of the space doesn't matter much - projects are still much
>shorter than C sources.

It'll make a difference when you fill that 50MB up.  Then the 50%
of space wasted in those BLOCKS will seem more important.

This is the kind of attitude that the "progressives" in this
newsgroup mention often... justification of why the "waste" of BLOCKS
is not important, or why it's OK for Forth source to be in a format
that is completely alien to the host OS.  Rationalization run rampant.

>
>MH>But with some of the arguments I've witnessed here for BLOCKS, I wouldn't
>MH>be surprized if someone proposed coding PKUNZIP in the interpreter to
>MH>expand zipped SCEENS for interpretation.
>
>:-) One of my users proposed something like this at the last FORTH
>Gesellschaft e.V. meeting. He said he'll try to implement it, but I never
>heard again ;-).

I'm not surprised.  Anything to keep from doing it in an industry-
approved manner.

>
>But tell me: why do screens hurt Forth if you can use stream files if you
>want?

Because they are so damn prevalent.  That's all that PD Forths support,
and after all, the file interface spelled out by dpANS is
*optional* is it not?  What wordset does BLOCK appear in?
This topsy-turvy heirarchy insures that BLOCKS stay visible to
newbies, and that's one of the things that is killing this language
in the general market.

>The most unpopular feature of Forth is the postfix notation. Why
>don't you start a flame war against this :-). It's realy not difficult to
>build an infix compiler for Forth (2 screens - or 32 lines, if you like
>that more :-).

Because there isn't anything about RPN that has been outmoded by another
technology and there is nothing inherent in it's use that hinders
the actual operation of Forth as a general purpose language.  It
actually is advantageous in an interactive environment, and is
architecturally well-fitted to the Forth interpreter.

None of these things are true about blocks.

The perception that RPN is a bad thing is in error, and RPN is
defensible on several fronts, among which it it's use in the
industry, probably the most well-known example is HP.

The perception that BLOCKs are a problem is accurate.