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

Category 1,  Topic 18
Message 1         Sat Jul 28, 1990
R.BERKEY [Robert]            at 00:00 PDT
 
  Frank Sergeant writes 900726:

  >Dennis, thanks for the pF info.  I'd like to hear even more about it
  >from any polyFORTH enthusiasts.

I've used polyFORTH and have something of a love/hate attitude toward it. 
It's been described as the personal programming tool of Charles Moore circa
1978, and he notes that he has made a point of throwing out things that aren't
really needed.  Yet without knowing the history of things that have been
removed, it's not necessarily obvious what's not there, and that there are
tools that can be easy to replace when needed.

An example involves the type of tasks that can be built.  The documentation
describes, and the system comes with tools to build, (1) background tasks
without terminal I/O, and (2) multi-programmer tasks with terminal I/O and
private dictionaries.  But with an understanding of the structure, it is
relatively easy to build tasks with terminal I/O yet without private
dictionaries.  Quiet hooks like this, I suspect, are the result of experience.
Whether of not this is design, polyFORTH deserves credit for keeping the
programmer's potential open.

"Don't limit your thinking to the way Forth comes", applies to polyFORTH: 
Don't limit your thinking to the way polyFORTH comes.  I found multi-tasking
systems difficult to debug.  But perhaps had I seen this as part of the
problem of the bug(s) I was fixing, I'd have spent some more time building
appropriate debugging tools.

Anyone who has ever added record and file locking to a database program in a
preemptive multitasking environment might agree that such a programming task
can be cumbersome.  Read record, read/write record, read file, read/write
file...make sure to lock the index file before locking the data file or expect
"deadly embrace" from another routine doing it in the opposite order...

I still find the block and buffer structure of polyFORTH combined with it's
round-robin multi-tasking environment to be somewhat amazing. With the right
programming touch, it's simply not necessary to do record and file locking. 
I've heard database designers agonize over the enormous task of permitting
large files to span disk devices.  With polyFORTH that capability comes with
the design, and therefore already bug free, speed optimized, etc.

And round-robin scheduling is a key.  Is building multi-tasking difficult?  I
assumed so until I saw that it can be done in three blocks of code, and with a
fast task switcher.  Preemptive operating systems may get so involved with
scheduling (I've heard) that they can spend half of their processor time just
in scheduling.

At another level I've found pF unpolished and user hostile. Unconventional
names is one aspect--words that look like ones you are used to but that
actually do something different.  An original designer knows all of the right
buttons to push to make something happen.  pF might have changed since 1982,
but at that time adding a user variable had four scattered and undocumented
places that needed to be modified. And the designer also knows pitfalls to
avoid.  For a simple example, there is an 8086 assembler segment move
instruction which uses DEST SOURCE syntax while with the rest of the move
instructions the syntax is SOURCE DEST.  I can still feel pain from having
fallen into various programmer traps in pF.

If pF is still like the 1982 versions there may be a long learning curve in
store for new users.  Yet pF is authentic Forth, which in my opinion is more
than can be said about many of the "Forth" systems available today.

-----
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