home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / forth / 3742 < prev    next >
Encoding:
Internet Message Format  |  1993-01-02  |  5.0 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!news.sei.cmu.edu!drycas.club.cc.cmu.edu!pitt.edu!pitt!willett!ForthNet
  2. Newsgroups: comp.lang.forth
  3. Subject: Documenting
  4. Message-ID: <4226.UUL1.3#5129@willett.pgh.pa.us>
  5. From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
  6. Date: 2 Jan 93 12:02:06 GMT
  7. Organization: EIEI-U
  8. Lines: 87
  9.  
  10. Category 3,  Topic 3
  11. Message 17        Fri Jan 01, 1993
  12. B.DUNN5 [Brian]              at 23:09 EST
  13.  
  14.  
  15.  > Screen files also allow loading individual screens,
  16.  > where text files usually require a total reload to finish
  17.  > compiling after an error in the middle of the file.
  18.  
  19.  A decent file text editor would allow a single keypress which would
  20.  backup the cursor to the start of the current definition ( back until
  21.  finding a line with a non-whitespace character in the first column ),
  22.  start loading at that cursor position, and when a new word is
  23.  defined, any previous definition with the same name would be patched to
  24.  call the new definition.  The load would then stop after the new word has
  25.  been defined.  The result is a single key redefinition of one word without
  26.  loading anything before or after.
  27.  
  28.  > I don't care how cool a Forth SCREEN editor you have... there are
  29.  > much better ones for text files.
  30.  
  31.  Every vendor should provide a spiffy editor built with and interacting with
  32.  Forth, regardless of screens or files.  It can be more useful than calling
  33.  an external editor from Forth via the operating system.  When it is
  34.  built in, you can do single definition reloads, word by word execution,
  35.  useful interaction with a Forth terminal program, have multiple copies
  36.  executing at a time, and all usually with much less memory, time, and
  37.  operating system overhead.
  38.  
  39.  > I hope I never again have to wind my way trough something like...
  40.  > 5 LOAD 8 LOAD 23 LOAD 100 110 THRU 56 LOAD 13 LOAD etc. etc. etc
  41.  
  42.  A good screen oriented system will often have some kind of directory.  The
  43.  above could become:
  44.    dload editor   dload terminal   dload extensions   dload decompiler
  45.  
  46.  It is possible to build a pseudo-file interface over a blocks system, with
  47.  block allocation tables and filenames.  Each file would really be a set of
  48.  physical blocks organized into a virtual sequence starting from virtual
  49.  block 0.  You would have fileIDs and tables to map virtual to physical.
  50.  To carry the concept out a little more, you could have the file be one
  51.  big block 64 characters wide and of unlimited number of lines.  The editor
  52.  would scroll through the entire file without 16 line page breaks.
  53.  
  54.  > There are things, that files are very unsuitable for. consider a
  55.  > sextet index of a Monte Carlo Simulation Program:
  56.  >        420 \ Polymers - Main                                PSP 22/11/92
  57.  >        421 \   Polymers - local                             PSP  3/06/92
  58.  >        422 \   Polymers - contd.                            PSP 30/05/92
  59.  >        423 \ Energy discretization                          PSP  2/11/92
  60.  
  61.  An indexer could be made on a file system by having a printout only of
  62.  lines where there is a non-whitespace character or even a special
  63.  character in column 1.  If this concept is applied to an editor, you could
  64.  have a keypress activate an outline mode, where only these lines appear on
  65.  the screen, you scroll to the section heading you wish to edit next, then
  66.  zoom back into the source code.
  67.  
  68.  > Even though the good editors have their
  69.  > languages, not is a flexible as FORTH is. They are pretty narrow too.
  70.  > On the contary one has the entire source of his editor in FORTH and
  71.  > implements whatever functions he considers usefull. And one ends up
  72.  > with a highly tuned to himself editor. 
  73.  
  74.  Imagine an editor or terminal program built with Forth, where you may
  75.  define a function key to fire off a definition you provide, with all the
  76.  power of Forth available for that action, plus access to common editor and
  77.  terminal functions.  This was put to very effective use with
  78.  an online starship game, where the other guys were using their simple
  79.  terminal macros to automatically raise shields and fire weapons, whereas
  80.  a single keypress on my own machine fired off little a Forth program which
  81.  automatically raised shields, launched decoys, started a sequence of
  82.  defensive maneuvers, scanned for the enemy, parsed their direction and
  83.  range from the input stream, immediatly selected and fired the
  84.  appropriate weapons for that range, monitored damage, and hit jammers and
  85.  dropped mines when it was time to bug out and run.  The response time,
  86.  parsing of useful information, and decisionmaking based on that information
  87.  made it the ultimate macro game program.  All using a simple built in
  88.  terminal which could fire off real Forth words from its function keys, with
  89.  access to useful functions provided for later use.  The same works with
  90.  an editor.
  91.  
  92. -----
  93. This message came from GEnie via willett.  You *cannot* reply to the author
  94. using e-mail.  Please post a follow-up article, or use any instructions
  95. the author may have included (USMail addresses, telephone #, etc.).
  96. Report problems to: dwp@willett.pgh.pa.us
  97.