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

Internet Message Format | 1993-01-22 | 7.1 KB

Path: sparky!uunet!noc.near.net!transfer.stratus.com!sw.stratus.com!nick
From: [e-mail] (Nicolas Tamburri)
Newsgroups: comp.lang.forth
Subject: Re: Documenting
Date: 22 Jan 1993 16:04:17 GMT
Organization: Stratus Computer, Inc.
Lines: 123
Distribution: world
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: kyron.sw.stratus.com

Bernd Paysan writes:
>
> 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....
>
> ...
>
> 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).
>
> ...
>
> 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 :-).

I think we have to get our definitions straight here.  Just because someone (you) has
written a language in Forth to run under Forth, does not put your Forth in the same
league as Unix or even MSDOS.  It is fine to have tiny pascal generate binaries which
can then be linked and run by an external OS as a regular application, external to the
Forth that ran the compiler.  It is great that some Forths save applications and data
as binaries to be read in later without re-interpretation.  Neither of these make the
originating Forth an OS.  The trick is to be able to read and run binaries generated by
external source, and unless I'm mis-interpreting you, bigForth, (nor any other Forth
I've ever heard of,) does this.  If you have this feature, then you do not need a C
compiler for bigForth,  you would be able to run the GNU C (or any other,) compiler
binary as a process under bigForth, and bigForth would have to provide that process with
its memory management, I/O management etc.  You publish the binary interface, or (even
better,) use an exiting one, and promise to provide the services needed by any
application which complies with that interface.  That is what an operating system
provides (even MSDOS,) not simply a promise to compile, save and read back any
program written in a particular language.

One can fake some things out:  If your Forth does not run native on a platform,
you may be able to spawn other tools from Forth and let the host OS provide those
services.  In this case, Forth becomes a SHELL (and a powerful one too!) but still
is not an OS.

You are correct:  Repeating a truth does not make it more true, it merely reinforces
it. Your naming applications that run under bigFORTH does not make it false either.

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

Do you have a seperate partition for running bigFORTH, or do you do the typical
Forth blocks on top of OS files on top of SCSI blocks?  Doesn't the latter seem a
little inefficient to you?

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

Wasting 50% of disk doesn't matter much...  So much for pushing Forth efficiency
in this area.

In this are your 'projects' start off with a 50% handicap in relation to a C
project before you even begin the design.  But that doesn't matter, and is
an arbitrary measurement;  I've C programs which are probably compact enough to
challange your claim, and I don't mind wasting  disk space to make program source
more readable.  You however are wasting it period.  The line between paragraphs of
this message costs (at most,) 2 bytes.  If these were screens, a blank line costs
64 bytes.  What you're really handicapping is the block side of this debate.
I consider the 50% disk space utilization caused by blocks unacceptable.
(Obviously you disagree, and I accept that you find the cost/benefit ratio of that
waste worth it for you.  I don't have an argument with that, and at least you admit
that there is waste.)

> 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!"

Screens do not hurt Forth if files are available.  What has fanned these flames are
those who advocate that block are the only way to go, and stream files are an
abomination to Forth.  (Although I believe it was MH who set fire to it all with
an incindiary message about how screens should go the way of the dinosaur.
Apologies beforehand if I'm wrong Mike.)

I tend to come down on Mike's side, and believe all new-comers should be steered
toward file usage, to introduce Forth as a language which can co-exist with their
existing environment and tools, rather than as a language which requires that
everything be done its way.  I don't believe blocks will make new-comers better
factorers, and I don't believe that files will make them write 2000 line word
definitions.  I believe that Forth is an incredibly liberating language.  Making
users conform their source to 64 character lines does not fit in with that
philosophy.  It's right up there with making all FORTRAN source start on
the 6th column of each line.

                                /nt