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

Text File | 1993-01-21 | 6.4 KB | 164 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: Fri, 22 Jan 1993 00:38:18 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: StarNine Technologies, Inc.
Lines: 152

In article <[e-mail]> [e-mail] (Bernd Paysan) writes:
>
>In article <[e-mail]>, [e-mail] (Mike Haas) writes:
>|> Forth uses blocks because it was almost always used in embedded
>|> controllers and on standalone computers which had little or no
>|> operating system.
>
>Oups, there were no embedded controllers with disk access in the early
>70th. Correct me, if I'm wrong. But in front of me is a disk from '69,
>with a nice headcrash and it's about 40".

So?  BLOCK doesn't have to access a disk.  The original FIG listings
references RAM like screens... I saved these screens to tape until
I managed floppy access.

And yes, there WERE standalone CPU boards with not only floppy connectors,
but ST506, also.

>
>|> It is nuts to suggest that blocks were implemented because they were
>|> thought superior to text files and to do so is rewriting history.
>
>Did you ever see this cards with little holes? THEY were the first mass
>storage. And they were treated as STREAMS. The invention of blocked mass
>storage is back to the first disks. Don't rewite history: stream is the
>elder concept. Blocked IO is newer.

I didn't say which was newer.  I simply stated that BLOCKS did not
happen because they were judged better than files for the same
implementations.  They came about to support development on non-file-
based systems.  That is their targeted environment, but using them
in a file-system is done at considerable cost.

Blocked I/O was developed to allow Forth to operate on any
environment that had any sort of mass storage, specifically to
facilitate development on non-file-based systems.

It is also a conceptually simple way to have the same interpreter
work from the keyboard and mass storage (although this is not at all
difficult to do with files, either).

>
>|> Not at all.  Simply change the interpreter such that it considers
>|> the end-of-line character or sequence to be another blank character.
>|> (y'know... the unconditional delimeter, most consider TAB, too).
>|>
>|> That's 99% of what's needed to get a Forth to work with
>|> files.
>
>And what if a word in a stream file is split over two IO blocks? You
>either have to read all the file at once in one big block (good for small
>files, bad for large ones) or realy to parse for end-of-line.

Yes, parsing for end-of-line is the whole point (that was the gist of
the above statement by me).  Having real end-of-line parsing is
a boon, especially when writing Forth programs that have to
deal with files produced by other STANDARD OS apps.

>
>|> Not using text files will indeed insure that many folks will never use
>|> any Forth tools.
>
>Many folks never will use any Forth tools anyway. Many folks even don't
>know the difference between WinWord format and plain ascii text (the
>Windows user who tries to change WIN.INI with WinWord is a typical
>example).

But many folks use WIndows.  And C.  And Pascal.  And assembly.  And ....
But not Forth.

BLOCKS, I feel, are one reason why.

>
>Using text files in big Forth systems (like JForth, bigFORTH or F-PC) is
>certainly a good idea.
>
>|> Forth is not an operating system.  It provides an execution
>|> environment on standalone computers, but it is no operating system.
>|> Nothing but Forth can operate under it's auspices.
>
>I always thougt an execution environment IS an operating system.
>Otherwise you should call MS-DOS not to be an operating system.
>
>The typical Forth as OS provides: Terminal and Disk IO, Multitasking and
>a way to load and execute programs.

The disk I/O is normally only BLOCKs.  With no concept of a file, it
is a useless operating system.

Those "programs" must be in Forth SOurce form.  This is a Forth
environment, NOT an operating system.

>It hosts editors, the Forth compiler
>(and sometimes other compilers like Forth cross compilers or tiny Pascal
>or tiny Basic and so on).

Only Forth code is "hosted".  Forth is not an operating system.

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

It is still a Forth-only environment... NOT an operating system.

>
>MS-DOS only provides Terminal and Disk IO and a way to execute programs.
>And even that is not true, look at the bulk of DOS-Externders for any
>useful program...

I'd agree that MSDOS is extremely limited and may not qualify as
a true OS.  It provides no GUI facilities, resource tracking, but
still is a GENERALIZED environment.


>
>|> Usre of blocks in no way increases one's efficiency.  In fact, it hinders it
>|> because you have to develop all your own print software, backup software,
>|> stuff that normal OS files live easy with.
>
>Per file backup should work. And to port print software you have already
>is an easy task.

And write some that doesn't is less easy.  And to write a 'diff' utility
for screens is even less easy.  Sooner or later, you're going to get
to something that's hard!

Seriously, even DOS provides this stuff for text files.  Why have to
re-invent it at all?  And when improved versions of DOS (or your text editor
or print spooler or ... ) appear, you will benefit by default.

>
>|> It's a helluva lot easyier to insert a new function in the middle of
>|> your program with files.
>
>bigFORTH:
>Alt I and a new screen is inserted at the actual position. Alt D and one
>is deleted. Even with long screen files it's fast on a HD.

Text files:
Press RETURN and a new line is entered.  You don't have waste 1023
characters to get that new line, either.

BTW, this idea of "inserting" a screen may apply to BigForth, but
not in most of them.  In fact, it's those Forths that use
screens-within-files that provide this capability.  And it's the
fact that there's a FILE SYSTEM underneath that allows you to do this!

Just go the next logical step and throw away the BLOCK layer.  There's
no reason for it on file-based platforms, and it's continuance
hurts Forth.