Path: utzoo!attcan!uunet!willett!ForthNet
From: ForthNet@willett.UUCP (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Experimental Ideas
Message-ID: <1417.UUL1.3#5129@willett.UUCP>
Date: 28 Jul 90 23:32:33 GMT
Organization: String, Scotch tape, and Paperclips.  (in Pgh, PA)
Lines: 84

Category 3,  Topic 5
Message 35        Sat Jul 28, 1990
D.RUFFER [Dennis]            at 00:01 EDT
 
Re: F.SERGEANT [Frank]

Not to dominate this polyFORTH discussion, but I'll try to keep it short this
time.  Ok, maybe I can't do that either.  :-)

 > maybe speed isn't everything

It is high on the list, but other factors such as memory and robustness can
sometimes be more important.  I've usually found that my time is better spent
on opimizing the time critical portions of the application than worrying about
optimizing the overall system.

 > Line editors.

You really have to see one done right before condeming them outright.  They
have their drawbacks, and I certainly don't recommend them for novices, but if
you are counting keystrokes you can't beat them.  Just think about it the next
time you are moving the cursor down to the bottom of the screen in your
favorite screen editor.  Count how many times the arrow key repeats and
compare that to the job of typing F followed by the string you moved the
cursor to, or T to the line number.  The efficiency is irrefutable, but the
ergonomics leave a little to be desired.  BTW do you also prefer a mouse to
the keyboard?  Just another efficiency compromise. :-)

No offense to L&P, but their line editor s..ks!  That was the first thing I re-
wrote when I started using F83.  I guess I am just spoiled.  The editor
certainly does have a big influence on the useability of a system, but no
matter how good a job you do on one, people will still prefer what they are
currently using.  I would say that poor editors have contributed to the bad
rap the block files have gotten, but screen editors can do just as bad of a
job as line editors can.  Wil Baden has some thoughts on this that he might be
kind enough to share with us.

 > Threaded vocabularies.

In polyFORTH, the search order is determined when you define the vocabulary
name, not by the vocabulary name.

I.e.  HEX 0315 VOCABULARY ASSEMBLER DECIMAL

defines the assembler vocabulary that searches thread 5 (assembler
definitions), then thread 1 (forth defs) and finally 3 (editor). The threads
are not specifically defined, but DEFINITIONS uses the first thread to put new
definitions in.  If you need to dynamically change the order, you need to
define another vocabulary name.  In other words, VOCABULARY does not define
new threads, but search orders into the existing threads.  In 16 bit
polyFORTH, you typically can have 8 threads (only odd 4 bit numbers are used),
but I've rarely had need for more.

 > 3 Character Names.

I did not mention it because I do not consider it a "feature", but an
annoyance I must deal with.  IMHO they cause more problems than they are
worth.  However, if you only have a 64K address space then they are almost
essential.  If you can address more than that, I think other alternatives can
be found that are much more appealing. Our polyFORTH product for MSDOS still
only uses 64K, but we are experimenting with other alternatives for our large
model systems.

 > Allen Test Product's big thing-a-ma-jig

Your description could either be the Smart Scope that I wrote, or the "son of
Smart Scope" the Smart Engine Analyzer (SEA).  You got most of the connections
right, and doing that part is relatively easy.  Of course you need to worry
about the 50,000 volt spikes coming out of the spark plugs, and how to store
and display the signals, but that's easy compared to problem of getting the
knowledge that is in their expert system.  I wrote the knowledge system, but
their automotive technicians supplied the knowledge.  If you want to build
your own, go out and buy all the service manuals you can get your hands on and
start typing.  When you've got it all entered, then try to debug it. :-)

 > what makes the perfect Forth?

When anyone can redefine the language at will, can it ever be perfect?  For
that matter, will it ever be finished?

I think not on both counts.   DaR
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu