NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/lang/forth/3789

Text File | 1993-01-07 | 4.6 KB | 104 lines

Newsgroups: comp.lang.forth
Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!torn!nott!uotcsi2!news
From: [e-mail] (Christopher Browne)
Subject: Re: Documenting
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: prge
Organization: Dept. of Computer Science, University of Ottawa
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 7 Jan 93 20:55:19 GMT
Lines: 91

In article <[e-mail]> [e-mail] (john r strohm) writes:
>Larry Maturo asks for reasons why one user prefers blocks over files.
>
>I offer the following for consideration.
>
>Blocks forces every single chunk of code to fit in a very restricted window,
>and it makes it darned near impossible to "slide" the window.  In my
>personal opinion, based on the code that I have seen, this restriction
>TENDS to force a greater degree of modularization, conciseness, and
>coherence, as compared to code developed under programming support
>environments that allow and even encourage the programmer to ramble on for
>hundreds of lines.

This is one of the classic arguments of the "BLOCK apologists."  While
the facts do go together, the causality isn't ALL that strong.  To
wit:

1: The word --> If you REALLY want to make words that extend between
screens, you can do so using -->.  It certainly isn't "darned near
impossible", because --> makes it quite possible.

2: FORTH may be "restrictive" in the area of code formatting, and may
attempt to "enforce discipline" in this area.  On the other hand, it
contains dictionary threading features that allow extensive use of
what often amount to "hacks."

On the one hand, FORTH tries to "force" you to FORMAT the code in
restrictive ways, but you can do an end-run by making up funny
syntaxes and CREATE DOES> words.

3: Pascal and Modula-2 are designed to "keep programmers from breaking
the rules" by having an almost Orwellian set of type checking
mechanisms, which cannot be turned off.

People that like Forth tend not to like THAT form of "programmer
control."  However, the BLOCK purists are proposing another different
form of "programmer control."

A competent Forth programmer SHOULD write the code using relatively
small fragments.  Whether these fragments come in the form of BLOCKs,
or as "stream" files should be of little relevance.  If you're
competent, the form of the file format shouldn't matter.

A Forth programmer can write unreadable code using blocks just as
easily as (s)he could with files.  --> is quite enough to give great
complications.  In addition, BLOCKs can be looked at as a form of
"goto" statement, which can be abused just as much as goto statements
ever could.

Sometimes "goto" is useful too, of course.  I'm surprised that nobody
has brought up the classical argument that "BLOCKs can be used to
implement virtual memory."  They most certainly ARE useful for that
purpose.  There may be some "alligators" in there if you're working
with pieces of data that might overlap blocks.  That goes with the
territory.

BLOCKS represent random access to data; files generally represent
sequential access to data.  Both are useful tools.  For organizing
source code, files are usually easier.

Has anybody tried using RCS in conjunction with a BLOCK based system?
I think not.  It assumes that there are carriage returns between
lines.  I suppose that one could write a utility to break blocks up
into lines, and back again as necessary.  It would be an ugly way to
do things, though.  It's easy with a file based system.

I would suggest that in a modern FORTH system, it should be POSSIBLE
to use both.  It's pretty easy to load code from either BLOCK or
stream.

In the case of an embedded controller, there may not BE anything
connected in the end, aside from an RS-232 connection.  In this case,
"streams" win out, since there is nothing that even resembles a BLOCK.
I think that EForth works this way.

If there's a block of RAM kicking around, it may be turned into a set
of BLOCKs.

But for a workstation based system, it makes little sense to restrict
it to BLOCKs.

I'd argue that I prefer to use "streams" for source code.  I would NOT
argue that it is USELESS to have a BLOCK system as well.  I'd prefer
to have the choice, because there are cases where each may be
necessary.

--
Christopher Browne                |     PGP 2.0 key available
[e-mail]           |======================================
University of Ottawa              | Genius may have its limitations, but
Master of System Science Program  | stupidity is not thus handicapped.