NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/lang/forth/3101

Text File | 1992-09-09 | 14.2 KB | 271 lines

Newsgroups: comp.lang.forth
Path: sparky!uunet!elroy.jpl.nasa.gov!decwrl!csus.edu!csusac!citrus!tree!alan
From: [e-mail] (Alan)
Subject: Re: Sampler Forth
Organization: The UNIX Tree Public Access *ix  [phone] Sacramento, CA
Date: Wed, 9 Sep 1992 17:45:52 GMT
Message-ID: <[e-mail]>
References: <[e-mail]>
Lines: 260

In article <[e-mail]> [e-mail] (John A. Peters) writes:
>SAMPLER FORTH                      Revised September 9, 1992
>
>Suggestions from the Silicon Valley FIG meeting August 22, 1992.
>Additional comments by letter from Jerry Mueller on Aug 29, 1992

>Most of us are too involved inside Forth and haven't backed off
>and looked at Forth through non Forth eyes.  We need to keep in
>mind that the visitor is not worried about speed or using to much
>memory or being redundant or figuring out how to actually do
>something.  The following will make Forth acceptable to the
>general public.  It's goal is to be conventional.

>FLOATING POINT default with a toggle words called FLO and INT.
>     The model is the simple pocket calculator.  Think of the
>     language Basic or a pocket calculator as the convention
>     people are used to.  Example: No F* fDUP or F/ etc.  Just
>     simple  *  /  +  -  in each mode.  Ideally the use off a
>     decimal point or comma will perform this toggle.

I used to hear the lack of floating point support defended as a
Forth virtue on a regular basis.  This was one of the most pathetic
arguments I'd ever heard and was reminiscent of "if God had meant us to fly
we'd have been born with wings." Thankfully, most of the dinosaurs
who were promoting this (along with block files) have apparently died or
evolved into birds.  Please understand, there was (and sometimes still
is) merit to using integer math and block files -- there's NO merit to not
having a choice.

>A lot of people resist RPN.  A lot of people have the idea that
>HP calculators are all RPN.  HP went with the flow and changed -
>their newer calculators all have algebraic entry, with RPN as an
>option.  Provide two Forth words: ALG (for algebraic) and RPN.
>Type ALG and you can type:
>(5*6)+(4*5)/(2*5)

>RPN entry.  This means that _(_  (paren) must always have a
>following space as is the case now.  With out a following space
>it is a algebraic instruction and should not be used for comments

>Sequential files with a toggle between .SEQ and .BLK files.  The
>     editor can read the file extension and do the right thing.

>A simple interface.

I may -- or may not -- agree with you, depending on what you mean by
"simple".  If you mean *stark* simple then I disagree -- the "simple
mindedness" of most Forth interfaces seriously dates them and generally
makes them anything BUT "simple to use."  A "simple" (aka "clean" and
smart) full screen interface would be an excellent idea.

>Error resistance and compiler security.  Range checking for
>     EXECUTE  ! "store", C!, MOVE, and CMOVE etc.

This is something which seems so obvious -- but I've never before
seen it suggested on the net.  Forth people like to argue things like
"but range checking will slow Forth down" and "if you properly factor
and use the stack you don't need range checking".  I heard analogous
Lilliputian-brained arguments used to defend the status quo line editors when
full screen editors were beginning to debut.  What would be wrong with robust
range and error checking which could be turned off once you got the kinks
worked out?  A while back there was discussion of writing an editor
similar to "emacs" with Forth as the embedded programming language.
One of the two biggest problems I saw with that idea is that people
wouldn't put up with an embedded programming language which might
crash and wipe out their document anytime they were running a new
"macro" on their text just because they made a silly logic/range mistake.

>Lots of Examples.  Three examples per concept at a minimum.

>Sound and color.

>Quick feed back (this we have)

An editable command history would be a very worthwhile addition.
Another very worthwhile addition along these lines would be support for
single character, user-definable "macro" words.  For instance "control-E"
might put you in the editor (as opposed to having to type "E <return>".
Alternatively, something like emacs' meta key could be supported.  Then
"macro" words could be more than one character and would be launched
automatically once enough characters were entered to uniquely identify
the macro.

>A full system with all the options already loaded.
This *might* get out of hand, depending on what you mean by "all the
options."  I think an alternative idea might be a *very* reliable,
*very* easy to use, full-screen "picklist" interface to words and
extension wordsets.  Behind the scenes Forth would have a simple
database which mapped requested words and wordsets to files and blocks
and which, hopefully, also handled "unloading"/deleting words which
were no longer needed.  What would it be like if, when you attempted
to execute a word which wasn't in the dictionary Forth *automatically*
loaded the word (perhaps with a warning to the user about what it
was doing) and then proceeded on its way?

>DOCUMENTATION; Use the resources of the machine!  The compiler
>doesn't do anything with numbers above 127, so use control-C to
>toggle the high-order bits to 1 and all incoming bytes are 128 or
>above and are ignored by the compiler.  They can be used for
>comments.  On the screen they're dimmer; the printer outputs then

>SO... a user could type FLO ALG SEQ at the forth prompt and be
>using floating point, algebraic and sequential.  Type FIX RPN SCR
>and you're a Forth purist.  Personally I don't care either way my

I think someone else already commented on the problem this would
introduce with regard to some non-english languages.  However, you're
certainly on the right track.  Having comments show up dimmed or in
a different color would be be marvellous.  I've always been fond of
the "shadow-screen" idea for comments, as well.  Having a short comment
which could be expanded into an unlimited length "shadow" comment at
the push of a key would be great and, possibly, unique.  You might
find an idea such as this would attract a LOT of attention and
admiration from users of other languages.  Documentation
is a major programming problem.  Intermixing commments with code
creates a visual clutter.  Distinguishing comments from code would
, as I've said, help a lot.  Good support of shadow blocks would be
a worthwhile extension of this idea.

>POWERFUL FEATURES that will help sell Forth.
>
>A usable link to C libraries and other black boxes.
>
>The ability to run in background as an TSR.  Example call and run
>
>A trace function and a debugger called BUG  i.e. BUG <word> which
>will work the same as DBG does..
>
>Typed values, Constants, and Variables were suggested at the
>meeting but Jerry says are we sure?

YES.  The lack of robust variables (including local variables) and
structures is costing Forth a lot of users.  New users have to start
programming somewhere and, I expect, many of them attempt to convert
an existing program or algorithm to Forth and give up in frustration.
In addition, data falls naturally into structures and I expect that
the lack of C-equivalent structures is a major headache even for more
advanced programmers.  I also suspect that the lack of
types and structures is a major reason why we haven't seen more Forth
applications.

>We need feed back and implementations.  If you have an idea, or
>opinion, write your self a note now, to call or write me.  If you
------
IMO this is one of the most incisive list of suggestions I've yet seen
on the net.  Forth is DYING, people.  I know some of you, such as JAX,
take issue with that and argue about how well Forth is doing in
embedded applications but I disagree.  Forth may be doing well in
embedded applications compared to, for instance, how poorly it is
doing in all other areas but that is about it.  As memory continues to
get cheaper Forth will be displaced from embedded applications, also.
ANSI may help but it won't save Forth.  Only an influx of new programmers
will save Forth and Forth is NOT going to get many new programmers unless
it becomes much more standardized and becomes an order of magnitude easier
to *LEARN*, USE, and WRITE commercially viable applications in.

I have a much better perspective on the problem than, perhaps, many of
you because I can't program worth beans in Forth.  Rather than making
me less qualified to comment on Forth I believe that makes me more
qualified.  You see, Forth was one of the very first languages I
attempted to use, dating back to early Fig (free) and LMI (commercial)
Z80 Forths.  Over the years I've LEARNED numerous other languages and
ATTEMPTED to learn numerous other Forths.  Some people, such as Mitch
Bradley, apparently blame the plethora of "free" Forths for the problem
but, IMO, they are mistaken.  I've tried commercial Forths, too, and
my experience is that they are only slightly easier to learn and NO MORE
PORTABLE than the free forths (I'm not talking here about portability
within one particular vendor's products -- I'm talking about being able
to take a program which runs under MS-DOS and get it to run under Unix
or the Mac using *another* vendor's (or perhaps a PD) Forth.  That is
the 'C' test for portability and it is the only test which
matters.  Without this level of portability it becomes difficult or
impossible for people to share code in the same way that C programmers
can.

Forth programmers seem to be "hung up" on how fast their Forth kernel
runs.  They don't seem to grasp the significance of the programming
truism "First get it right.  THEN make it smaller, faster, slicker,
etc."  They don't seem to recognize that speed of learning, speed of
developing/modifying and speed of porting/maintaining are valid goals.
IMO the latter are the MOST valid goals and without a new mindset which
embraces them, Forth will continue its decline toward insignificance.
Making "speed of execution" the God to which you sacrifice all other
virtues has produced the phenomena where Forth programmers apparently
write more Forth implementations than applications.  Mitch, Elizabeth,
and other vendors decry the proliferation of Forths but none of them
apparently want to follow their own advice.  If you REALLY want to
help the Forth cause and have a successful company, Mitch, consider
giving up your own Forth implementations in favor of creating good
applications and tools which run portably on other vendor's
implementations.  You sure won't have any competition.

The focus on execution speed at all costs ignores the facts that:
(a) Forth is NEVER  going to be the fastest executing language.  There
is too much money being spent by the 'C' vendors to continually
optimize their compilers.  If you try to compete with 'C' on execution
speed alone you are going to lose.  You might as well shoot yourself
in the head and get it over with.
(b) Speed of learning, developing applications, porting, and supporting
are are areas where Forth likely *could* beat 'C' hands-down *if*
Forth programmers would change their focus.  And, in the long run,
many programmers and most companies care more about these time-wasting
aspects of programs than they do about sheer execution speed. It's
hard to run *anything* "slowly" on a 50 MHz 486.
(c) If a user could *quickly* port a working version of a good
application to his/her desired platform they would then be a much
better mood and position to then go back and "optimize" it.  Give
me a portable editor/database/game -- almost no matter how "slow" it
runs -- and as I familiarize myself with the language and the code
I will incrementally  improve its speed.  Give me a program which is
a "speed-demon" on a particular vendor's particular Forth for a
particular machine and you will, almost certainly, be giving me
grossly non-portable, difficult to understand code.  And, rather than
attempt the port, I will, almost certainly, throw it -- and Forth
-- in the trashcan.  This is a very common experience with Forth.  The
worst thing about having this happen is that people tend to carry a
grudge and remember the language (not just the application or the
implementation) which stung them.

I have a few final comments on the proposed "easy to learn" Fig Forth:

(1) worry only the Intel and Motorola families of processors but make
the systems 100% compatible.  Do NOT sacrifice anything fundamentally
important for the sake of the bottom of the line (i.e., 8088) processor.
I just bought a 50 MHz 80486 with 8 megs RAM, a 200 MB harddisk and an
SVGA monitor for $2200.  Anyone who doesn't value their time enough to
upgrade from an 8088 now to, at least, a 386SX is unlikely to be an
important convert to Forth.  If you are going to worry about them you
might as well worry about the folks who are still using Timex
Sinclairs.

(2) Make sure that source libraries are 100% portable.

(3) Make sure that you include powerful and easy to use string, file,
and screen manipulation libraries.  It should be approximately as
easy for a newcomer to concatenate two strings, files, or screen
displays as it is to add two numbers.  Forth texts like to demonstrate
the ease of use of the language by showing "3 5 + .".  They omit
(or spend chapters) discussing how to do the equivalent string, file,
and screen operations.  Get a clue.

(4) Include with the libraries at least one or two "significant"
applications which make wide use of the libraries and are 100% portable.
As has been pointed out before, a portable and impressive editor, database,
or video game would work wonders in promoting Forth.  The source code could
be examined and adapted to numerous other applications.

I apologise if I've inadverently offended anyone or said anything which
indicates my "ignorance" of Forth.  Let me end with a parting outrageous
and gross generalization which likely, nevertheless, has a lot of validity:
Change *Forth* to make *me* happy and you'll probably have done 95% of
what needs to be done to give Forth a new lease on life.  The proposals
made the Silicon Valley FIG are right on.  Those of you who
significantly disagree -- no matter how well intentioned you may be --
are the problem and you are strangling to death the language you profess
to love.
--

-----
[e-mail]  or uunet!csusac!tree!alan