home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / forth / 3972 < prev    next >
Encoding:
Text File  |  1993-01-23  |  3.3 KB  |  80 lines
  1. Newsgroups: comp.lang.forth
  2. Path: sparky!uunet!usc!sol.ctr.columbia.edu!venezia!penev
  3. From: penev@venezia (Penio Penev)
  4. Subject: Re: Documenting
  5. References: <C18CFv.GtA@starnine.com>
  6. Sender: nobody@ctr.columbia.edu
  7. Organization: Rockefeller University
  8. Date: Sat, 23 Jan 1993 11:54:26 GMT
  9. X-Newsreader: TIN [version 1.1 PL6]
  10. Message-ID: <1993Jan23.115426.24547@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: 64
  15.  
  16. Mike Haas (mikeh@starnine.com) wrote:
  17. : In article <1993Jan14.122149.16814@Informatik.TU-Muenchen.DE> pazsan@Informatik.TU-Muenchen.DE (Bernd Paysan) writes:
  18. : >|> Usre of blocks in no way increases one's efficiency.  In fact, it hinders it
  19. : >|> because you have to develop all your own print software, backup software,
  20. : >|> stuff that normal OS files live easy with.
  21. : >
  22. : >Per file backup should work. And to port print software you have already
  23. : >is an easy task.
  24. : 
  25. : And write some that doesn't is less easy.  And to write a 'diff' utility
  26. : for screens is even less easy.  Sooner or later, you're going to get
  27. : to something that's hard!
  28. : 
  29. : Seriously, even DOS provides this stuff for text files.  Why have to
  30. : re-invent it at all?  And when improved versions of DOS (or your text editor
  31. : or print spooler or ... ) appear, you will benefit by default.
  32.  
  33. Well, DOS doesn't. It fails on the first inserted char.  But this is
  34. not the point. I program in FORTH since 1985 and have never needed
  35. such a utility. Sure, if I have needed it, I should have written one.
  36. I wrote an (screen) editor, though. It was fun, easy and is the best
  37. editor I've ever used. And the most portable editor I've ever used too.
  38.  
  39. : 
  40. : >
  41. : >|> It's a helluva lot easyier to insert a new function in the middle of
  42. : >|> your program with files.
  43. : >
  44. : >bigFORTH:
  45. : >Alt I and a new screen is inserted at the actual position. Alt D and one
  46. : >is deleted. Even with long screen files it's fast on a HD.
  47. : 
  48. : Text files:
  49. : Press RETURN and a new line is entered.  You don't have waste 1023
  50. : characters to get that new line, either.
  51. : 
  52. : BTW, this idea of "inserting" a screen may apply to BigForth, but
  53. : not in most of them.  In fact, it's those Forths that use
  54. : screens-within-files that provide this capability.  And it's the
  55. : fact that there's a FILE SYSTEM underneath that allows you to do this!
  56.  
  57. Well, the file system has nothing to do with it. When You insert a
  58. screen You copy a block range one screen further. This You can do on
  59. any BLOCK system. And text editors do the same. I've never seen an OS
  60. function "isert bytes(blocks) at the file pointer". I know CPM, DOS &
  61. UNIX. I may be wrong for the rest OSes.
  62.  
  63. : 
  64. : Just go the next logical step and throw away the BLOCK layer.  There's
  65. : no reason for it on file-based platforms, and it's continuance
  66. : hurts Forth.
  67. : 
  68.  
  69. Everybody may use whatever he wants, even BLOCKS. The questions is
  70. whether BLOCKS vs. text files matters for having a good production
  71. environment. I'm sure, that FORTH can be a good one with both. Perhaps
  72. the experience of the companies using FORTH should sumarised in a
  73. book to see the approaches. Surely all of the standard approaches will
  74. work. The question is what is best suited to the particular needs. And
  75. the answers is it depends on the needs. So no general solutions are
  76. good. Some may be just OK.
  77.  
  78. -- Penio.
  79.  
  80.