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

Internet Message Format | 1993-01-26 | 3.8 KB

Path: sparky!uunet!noc.near.net!transfer.stratus.com!sw.stratus.com!nick
From: [e-mail] (Nicolas Tamburri)
Newsgroups: comp.lang.forth
Subject: What's wrong with screens (Re: Documenting)
Date: 26 Jan 1993 14:25:19 GMT
Organization: Stratus Computer, Inc.
Lines: 60
Distribution: world
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
NNTP-Posting-Host: kyron.sw.stratus.com

penev@venezia (Penio Penev) writes:
> Chuck Eaker ([e-mail]) wrote:
> : However, the insert commands in typical Forth block editors
> : usually cause a number of characters (equal to the number of
> : inserted characters) at the end of the line or the end of the
> : block to be discarded. This is not true of file based editors.
> : I don't especially care for this block editor behavior.
> : It's an implementation quirk that requires attention, and, in
> : the old days, often distracted me from the real work I was trying
>
> I avoid data loss by pressing the key for UNFLUSH, which copied the
> current screen to a safe location (screen 0) and re-reads the block
> from disk. I have rarely been unhappy about this.

I'm pleased to hear that you have found a way around this limitation with
screens/blocks.  Unfortunately I've never heard of UNFLUSH, so I don't think
it's a standard word.

One of the problems with this whole discussion is that when someone brings up
a shortcoming in screens, those who use screens have come up with a nifty way
of getting around the shortcoming, or the imaginitive ways they have for organizing
their source etc.    I've actually found some of these messages informative (esp.
the the messages long ago from E. Rather and Dick Miller, which were eye openers
for me.)  But this issue is about fundamental concepts in the language,  not
about how various implementations give you work arounds for screens' limitations.

Not one block proponent has yet to address the issues of interoperability with
other system tools and utilities.  The only argument that comes close is "write
your own, it's not that difficult in Forth."  I for one don't have the time to
write my own applications, much less rewriting existing tools.  I refuse to rewrite
GNU emacs in Forth, and I refuse to use a more limited editor to write my Forth
code.  I shouldn't have to, and I will not choose a Forth that forces me to.

If Forth's vendors wish to survive, they must address this issue;  not adapatability,
(Forth is already that,) but interoperability.  [I'm sure Forth will survive,
because even as I write, someone is writing their own version, rather than getting
something useful done (like me :-)]  To me this essentially means 3 things:
link foreign libraries,  provide calling mechanisms into the OS directly and
coexist with the file system.  Happily, most Forth systems I've seen are moving
in this direction.  Vendors know the value of providing these functions.  (The
market has chosen, as Elizabeth Rather would say.)

What is surprising about this discussion is that there is so much opposition to
these changes from existing users.  It is not enough for them to keep with their
way of doing things, (and there is nothing wrong with working with what has been
comfortable for years,)  but to vociferously oppose these changes for others
is incomprehensible to me.  Such opposition goes against the very argument of
Forth's adaptability.

> Again, I do not say, that everybody must use blocks (or FORTH even). I
> say that works fine for me. _Much_ finer, than text files (or C).
>
> -- Penio.

Good, I'm glad to hear it.  I don't want to drag you kicking and screaming into
the light either.  But the real issue in this whole discussion was, and still
is, when a new user asks about how to use Forth,  which storage system will be
introduced.  I hope that it will be files.

                                /nt