home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / forth / 3104 < prev    next >
Encoding:
Internet Message Format  |  1992-09-10  |  3.0 KB
  1. Path: sparky!uunet!sun-barr!west.West.Sun.COM!cronkite.Central.Sun.COM!texsun!exucom.exu.ericsson.se!news
  2. From: exuhag@exu.ericsson.se (James Hague)
  3. Newsgroups: comp.lang.forth
  4. Subject: Re: Sampler Forth
  5. Message-ID: <1992Sep10.142241.11172@exu.ericsson.se>
  6. Date: 10 Sep 92 14:22:41 GMT
  7. References: <1992Sep9.174552.22223@tree.UUCP>
  8. Sender: news@exu.ericsson.se
  9. Reply-To: exuhag@exu.ericsson.se
  10. Organization: Ericsson Network Systems, Richardson, TX
  11. Lines: 55
  12. Nntp-Posting-Host: s09a05.exu.ericsson.se
  13.  
  14. Excellent post, Alan, which hit the nail right on the head.
  15.  
  16. I agree that most Forth implementations are severely misguided.
  17. (I am not talking about Forths for embedded use here, but Forth
  18. as a general purpose programming language.)  I'm of the "Forth
  19. should be small and understandable" school, but this doesn't
  20. mean that a Forth system has to be as rickety as the Apple II
  21. ML monitor.
  22.  
  23. Speed *is* overrated.  It is mostly a psychological thing; people
  24. for some reason, no matter how fast their processor may be, hang
  25. on to the same misconceptions:  BASIC is slow, LISP is slow, C is
  26. super-fast. etc.  And they are willing to trade convenience and
  27. ease-of-use for every extra bit of speed.  Indirect-threaded FIG
  28. Forth on a 6502 was a very usable system--much faster than interpreted
  29. BASIC.  Yet on an 80386 it isn't fast enough and we have to resort
  30. to all sorts of fancy inline code schemes.
  31.  
  32. I'd like to see the following features in a Forth implementation
  33. (I do most of my non-work programming under MS-DOS, so keep this
  34. in mind):
  35.  
  36.      * Crashproof (FORTHMACS does this, so I hear).  You shouldn't
  37.        be able to type a word from the keyboard and bring down the
  38.        whole system.
  39.  
  40.      * An editor which is well-integrated into the system and takes
  41.        advantage of available features:  color, arrow keys for cursor
  42.        motion, etc.  I don't consider loading an external editor to
  43.        be good integration.  It doesn't need to be fancy, just _solid_.
  44.  
  45.      * A better alternative to FORGET.  There's no reason any more to
  46.        stick to the old linear dictionary model, IMO.  All you want to
  47.        do is create and delete words.  Use the heap.
  48.  
  49.      * One-key meta or true compilation.  The resulting executables should
  50.        be as small as possible.  I can't stand 150K "hello world" programs.
  51.  
  52.      * A nice environment, something more than just being able to
  53.        enter Forth words.  Use the up/down arrows to scroll through
  54.        a history list.  Have a pop-up window to let you visually select
  55.        files.  Tab for filename completion.  A DOS shell.
  56.  
  57.      * Ability to switch between environment screen and screen of running
  58.        program.  Graphics settings and such are automatically saved without
  59.        hassle.
  60.  
  61. These are the sort of things I would expect from a modern Forth
  62. implementation.  I think you could get everything listed above into
  63. a 50K exectuable without any problems.  I don't see many problems with
  64. Forth itself (i.e. RPN, etc.), just the usual programming environment.
  65.  
  66. --
  67. James Hague   
  68. exuhag@exu.ericsson.se
  69.