From: pazsan@Informatik.TU-Muenchen.DE (Bernd Paysan)
Subject: Re: Documenting
Originator: pazsan@hphalle4g.informatik.tu-muenchen.de
Organization: Technische Universitaet Muenchen, Germany
Date: Fri, 22 Jan 1993 10:57:59 GMT


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.

me>Some Forths even have ways to save applications
me>as binary and reload them very fast (i.e. my bigFORTH). These Forths even
me>provide something an Unix would call "Shared Libraries". A host of Forths
me>provide multiuser abilities.

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 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).

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.

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 :-).

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. BLOCKs are the right primitive to implement any sort of disk I/O.
You OS uses blocks, too. Cut it out and try to work ;-).

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

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.

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 ;-).

But tell me: why do screens hurt Forth if you can use stream files if you
want? 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 :-).
-- 
Bernd Paysan
"Late answers are wrong answers!"
Newsgroups: comp.lang.forth