home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / forth / 4024 < prev    next >
Encoding:
Text File  |  1993-01-28  |  5.6 KB  |  107 lines
  1. Newsgroups: comp.lang.forth
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!howland.reston.ans.net!paladin.american.edu!gatech!emory!sol.ctr.columbia.edu!venezia!penev
  3. From: penev@venezia (Penio Penev)
  4. Subject: Re: What's wrong with screens (Re: Documenting)
  5. References: <1k3hkfINNjgk@transfer.stratus.com>
  6. Sender: nobody@ctr.columbia.edu
  7. Organization: Rockefeller University
  8. Date: Wed, 27 Jan 1993 04:01:53 GMT
  9. X-Newsreader: TIN [version 1.1 PL6]
  10. Message-ID: <1993Jan27.040153.14435@sol.ctr.columbia.edu>
  11. Reply-To: penev@venezia.rockefeller.edu
  12. X-Posted-From: venezia.rockefeller.edu
  13. NNTP-Posting-Host: sol.ctr.columbia.edu
  14. Lines: 91
  15.  
  16. Nicolas Tamburri (nick@sw.stratus.com) wrote:
  17. : penev@venezia (Penio Penev) writes:
  18. : > Chuck Eaker (eaker@ukulele.crd.ge.com) wrote:
  19. : > : However, the insert commands in typical Forth block editors
  20. : > : usually cause a number of characters (equal to the number of
  21. : > : inserted characters) at the end of the line or the end of the
  22. : > : block to be discarded. This is not true of file based editors.
  23. : > : I don't especially care for this block editor behavior.
  24. : > : It's an implementation quirk that requires attention, and, in
  25. : > : the old days, often distracted me from the real work I was trying
  26. : > 
  27. : > I avoid data loss by pressing the key for UNFLUSH, which copied the
  28. : > current screen to a safe location (screen 0) and re-reads the block
  29. : > from disk. I have rarely been unhappy about this.
  30. : 
  31. : I'm pleased to hear that you have found a way around this limitation with
  32. : screens/blocks.  Unfortunately I've never heard of UNFLUSH, so I don't think
  33. : it's a standard word.
  34. : 
  35.  
  36. No, this is not standard and is implementation specific. Since I'm
  37. stuck with a particular implementation, I've been using it across
  38. many platforms without touching. Although the point of Nickolas was
  39. about principles, rather than workarounds, I'll post the code for the
  40. sake of completeness. Note, that it depends on the mechanism of the
  41. linking of block numbers with buffers in memory. It relies on changing
  42. the block number of the buffer with the corrupted data.
  43.  
  44. PREV holds an offset to the number of the most recently accessed block.
  45. IDENTIFY  marks the newest buffer ( in PREV) with the block
  46.    number from the stack, with  OFFSET  added.
  47. s d COPY  copy block s to block d .
  48.  
  49. : IDENTIFY ( n)  OFFSET @ +  PREV @  PREV +  4+ ! ;   
  50. : (COPY) ( s d)   SWAP BLOCK DROP  IDENTIFY  UPDATE ;
  51. : COPY ( s d)  FLUSH (COPY) ;
  52. : RECOVER   SCR @  0 (COPY)  DISPLAY ;
  53.  
  54. Well, as I see I've name this word RECOVER, rather that UNFLUSH. This
  55. was too long ago.  DISPLAY is the equivalent of SCR @ LIST in the
  56. screen oriented editor.
  57.  
  58. : One of the problems with this whole discussion is that when someone brings up
  59. : a shortcoming in screens, those who use screens have come up with a nifty way
  60. : of getting around the shortcoming, or the imaginitive ways they have for organizing
  61. : their source etc.    I've actually found some of these messages informative (esp.
  62. : the the messages long ago from E. Rather and Dick Miller, which were eye openers
  63. : for me.)  But this issue is about fundamental concepts in the language,  not
  64. : about how various implementations give you work arounds for screens' limitations.
  65.  
  66. Everything has limitations. The processor has limitations, the
  67. technology has limitations, the human biology has limitations, the
  68. speed of ligh has limitations. The questions is what are the
  69. advantages of limiting Yourself. You loose the ability do do something
  70. efficiently (or at all), but get the ability to do other things
  71. faster. The judging is a matter of balance.
  72.  
  73. : Not one block proponent has yet to address the issues of interoperability with
  74. : other system tools and utilities.  The only argument that comes close is "write
  75. : your own, it's not that difficult in Forth."  I for one don't have the time to
  76. : write my own applications, much less rewriting existing tools.  I refuse to rewrite
  77. : GNU emacs in Forth, and I refuse to use a more limited editor to write my Forth
  78. : code.  I shouldn't have to, and I will not choose a Forth that forces me to.
  79.  
  80. I use GNU emacs to write these lines. It has its virtues. But if I
  81. wanted to write a FORTH-major-mode, It would have to mimic my FORTH
  82. editor. So why bother? You can program in Elisp, You can do it in
  83. FORTH. If I used emacs, I'd add another layer of complexity (interacting
  84. between FORTH and Emacs) without gaining functionality. And of course
  85. my FORTH editor's source is _much_ more manageable than Emacs'es
  86. source. In general, I use a text file editor for text files and a
  87. program editor for program files. Both tasks are _very_ different from
  88. each other.
  89.  
  90. : If Forth's vendors wish to survive, they must address this issue;  not adaptability,
  91. : (Forth is already that,) but interoperability.  [I'm sure Forth will survive,
  92. : because even as I write, someone is writing their own version, rather than getting
  93. : something useful done (like me :-)]  To me this essentially means 3 things:
  94. : link foreign libraries,  provide calling mechanisms into the OS directly and
  95. : coexist with the file system.  Happily, most Forth systems I've seen are moving
  96. : in this direction.  Vendors know the value of providing these functions.  (The
  97. : market has chosen, as Elizabeth Rather would say.)
  98.  
  99. Yes, I use all of these ( foreign libraries, calling mechanisms into the
  100. OS, file system support). On one system You have to talk to a UART, on
  101. another to a robot arm control register, and on UNIX You have to talk
  102. to X terminals. For everything You build a little lexicon with the
  103. interface and do Your job. You treat X terminal like external devices
  104. with their own copntall language. What's the problem?
  105.  
  106. -- Penio.
  107.