thomson@wasatch.utah.edu (Rich Thomson) (08/13/89)
Amiga FORTH Programmer's Newsletter Contributions:
Volume 2 amiga-forth@cs.utah.edu
Number 2 Add/Delete/Archive Requests:
August 12th, 1989 amiga-forth-request@cs.utah.edu
Archives available by anonymous ftp to:
cs.utah.edu in pub/amiga-forth
Contents:
re: KEY (David_N._Williams@ub.cc.umich.edu)
FStrings (David_N._Williams@ub.cc.umich.edu)
______________________________________________________________________________
Date: Mon, 7 Aug 89 21:52:26 EDT
From: David_N._Williams@ub.cc.umich.edu
Subject: re: KEY
As a new member of this newsletter, I've enjoyed reading through all the
back issues (thanks to anonymous ftp).
I noticed in the discussion started by Marcus Gabriel about echoing with
KEY in multi-forth, nobody mentioned "just" opening a console device and
using SendIO, DoIO, etc. If you do that in your own window, keyboard
input is not echoed to the screen, whether you "run" the application or
not. I've done it both that way and with raw Intuition input, as Phil
Burk points out that JForth does--each method has its uses.
Maybe somebody who's not a lapsed developer knows whether NewCon: allows
the programmer to get lines after command line editing? (Is it NewCon:
that does command line editing and history, or is it AShell?) If so,
that might be a cheap way to put editing into EXPECT.
AForth, by the way, opens a console device, and its KEY doesn't echo.
--David W.
______________________________________________________________________________
Date: Mon, 7 Aug 89 21:54:50 EDT
From: David_N._Williams@ub.cc.umich.edu
Subject: FStrings
I especially appreciated the second issue of this newsletter on strings,
provided by Marcus Gabriel. The treatment of strings in most languages
has been a pet peave of mine for some time, because it seems to me
things have mostly gone down hill as far as everyday languages are
concerned (i.e., omitting Snobol, Lisp,...), after having peaked in the
earliest MicroSoft BASIC's. I mean, if plain old BASIC can arrange it
so we never have to keep track of string sizes or buffers, how can we
stand to have it otherwise in "real" languages?
Although the garbage collection algorithm in those BASIC's was pretty
slow (on the rare occasions when you were forced to be aware of it), and
I don't know that Bill Gates actually invented it for himself as a
teenager, it certainly is pleasant to think that he probably did. If he
did, how come the rest of the world has been so slow to pick up on it?
I know from experience a few years back that it doesn't take that much
programming effort to do a fast garbage collection algorithm. (I didn't
know about Knuth, then; a major aspect of the algorithm I came up with
is in one of his volumes.)
So it was encouraging to see the discussion by R. J. Brown in his
"GStrings" proposal, which uses a pretty sophisticated garbage
collection algorithm. But I do have some remarks about his proposal and
the FStrings proposal by George Hawkins which it is intended to extend.
First of all, to pick a nit, I hope the "$$" notation that Hawkins
proposes doesn't become standard. For example, string concatenation by
its nature is a binary operation; and I think it's too much to call it
"$$+" instead of simply "$+", or to use "$$!" instead of "$!".
I also felt that Hawkins was too timid in not following his inclination
to have a separate string stack. I can't see how to have garbage
collection without a separate string stack; and my contention is that
one shouldn't be satisfied with less--you have to have garbage
collection. The point is that if you have string pointers on the
parameter stack, they become invalid when you do a garbage collection;
and there's no way to distinguish them from ordinary data to correct
them.
Having a separate string stack allows a more expressive syntax anyway.
But aside from that, I really liked Hawkins' proposal. The primitives
are very nicely thought out.
R.J. Brown doesn't mention that his proposal, since it does garbage
collection, requires a string stack; but his idea seems interesting to
me. He was apparently throwing it out for feedback. It doesn't seem
wise to make any particular algorithm into a standard--somebody's always
going to come up with a better one. But maybe that's not what he's
suggesting.
Maybe this stuff is already outdated. Does anybody know about more
recent developments?
--David W.
______________________________________________________________________________