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

Text File | 1993-01-28 | 5.3 KB | 103 lines

Newsgroups: comp.lang.forth
Path: sparky!uunet!math.fu-berlin.de!informatik.tu-muenchen.de!paysan
From: [e-mail] (Bernd Paysan)
Subject: Re: Documenting
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Originator: [e-mail]
Sender: [e-mail] (USENET Newssystem)
Organization: Technische Universitaet Muenchen, Germany
Date: Thu, 28 Jan 1993 11:57:10 GMT
Message-ID: <[e-mail]>
Lines: 90


I only want to pick out some lines of your long article:

MH>No, under a normal OS, it's primitives are the right ones, and
MH>there is no reason to implement BLOCK because:
MH>
MH>   1. Many disk ops read/write MUCH less than 1024 bytes.
MH>   2. OS's provide their own block-style buffering and usually
MH>      in chunks less than 1024 bytes.

Oups. Both my hard disk and my floppy works in chunks exactly 1 K (2
sectors/cluster). Here the HP-UX works with chunks from 512 byte to 4 K,
depending on the size of the disk. My MS-DOS PC works with chunks of 1K for DD,
and 512 bytes for HD floppies. The hard disk read in chunks of 4K, because it is
one partition of 105 MB and it can't be less (8 sectors/cluster).

But your second argument is exactly what I say: OS provide block-style buffering
at their low level disk I/O. The OS has to implement block. And if you read
chunks with block-size, the OS works at best. Reading much less than 1K results
in incredibly high overhead.

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

And the Church's thesis says: Then it supports everything else, too, because you
can do everything else once you can do it in Forth (or in Turing machine). Forth
is an universal language, and has good performance, too (which Turing's machine
hasn't).

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

And Unix is called "The best programmer's editor" (from Unix freaks, that's not
the flame of a Unix-hater).

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

I KNOW about operating systems, other languages and real-world uses for
computers. And there are many computers that run only FORTH and nothing else.
According to your words, they won't work, because they have no OS, but only an
interactive language running. How does it run, without OS? If you realy NEED a
file system, why didn't everybody implement it? And I'll give you a reference:
There was an article in the "Vierte Dimension", the german Forth magazine, I
think in 1/89, about "Block World", a unix-style file system implemented by using
the block interface. The implementation differs much from Unix, but the
functionality is about the same.

To your claim about "tiny basic": As far as I know, tiny basic implements all
features of ANSI BASIC (which are few enough to call it "tiny"). Tiny pascal is
about the same: You can't compare it with Turbo-Pascal, but it is Pascal. I
think, tiny pascal is distributed with F-PC or related to F-PC.

MH>In my mind, the Forth community needs to spend more time figuring out how
MH>to get Forth to LIVE EASILY under real existing operating systems.
MH>Throw out blocks would be a good start.

Why do you want to throw out blocks? bigFORTH, LMI Forth, JFORTH and others live
easily under real existing operating systems or MS-DOESn't. There is no READLINE
in many existing operating systems, this is only a C/Forth/Pascal library
function. So stream files with line ends are no real parts of operating system.
Just the other way round: Two years ago, here was a 370 compatible mainframe from
Siemens, running IBM's CMS/VMSP. This OS uses fixed records for storing text
files. Waste of space? Doesn't count. The earlier versions of OS/370 allocated one
cylinder for each file. Hundrets of KB wasted. Very efficient for large files
like data bases or so.

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

The rest of my 50 MB are filled up with text files, binaries and stuff like this.

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

Block files aren't completely alien to the host OS. Only native blocks without
files are alien. Conversion is stupid simple. If you don't like blocks, throw
them out in your Forth. I don't want my costomers run away, if I do so. I don't
want my applications to stop run. I don't want to convert all my source files. If
I really need the space, I'd add an online compressor (Data Light for the ST and
Superstore for the PC). They even save 50% or more on stream files. And except
the performance penalty you don't see them.
--
Bernd Paysan
"Late answers are wrong answers!"