home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / forth / 3956 < prev    next >
Encoding:
Text File  |  1993-01-22  |  5.1 KB  |  104 lines
  1. Newsgroups: comp.lang.forth
  2. Path: sparky!uunet!math.fu-berlin.de!informatik.tu-muenchen.de!pazsan
  3. From: pazsan@Informatik.TU-Muenchen.DE (Bernd Paysan)
  4. Subject: Re: Documenting
  5. References: <1492@eouk9.eoe.co.uk> <C0ry23.8Dy@starnine.com> <1993Jan14.122149.16814@Informatik.TU-Muenchen.DE> <C18CFv.GtA@starnine.com>
  6. Originator: pazsan@hphalle4g.informatik.tu-muenchen.de
  7. Sender: news@Informatik.TU-Muenchen.DE (USENET Newssystem)
  8. Organization: Technische Universitaet Muenchen, Germany
  9. Date: Fri, 22 Jan 1993 10:57:59 GMT
  10. Message-ID: <1993Jan22.105759.20424@Informatik.TU-Muenchen.DE>
  11. Lines: 91
  12.  
  13.  
  14. me>It hosts editors, the Forth compiler
  15. me>(and sometimes other compilers like Forth cross compilers or tiny Pascal
  16. me>or tiny Basic and so on).
  17.  
  18. MH>Only Forth code is "hosted".  Forth is not an operating system.
  19.  
  20. Forth + tiny Basic HOSTS basic. You can do SAVESYSTEM or save tiny basic
  21. as an binary application. Many operating systems hosts only native code.
  22. You can't call this: "Only native code is hosted". As soon as you host
  23. native code (it doesn't matter if it's the native code of the real
  24. machine or of any virtual machine), you host everything. My Forth hosts
  25. native code - so it hosts everything.
  26.  
  27. me>Some Forths even have ways to save applications
  28. me>as binary and reload them very fast (i.e. my bigFORTH). These Forths even
  29. me>provide something an Unix would call "Shared Libraries". A host of Forths
  30. me>provide multiuser abilities.
  31.  
  32. MH>It is still a Forth-only environment... NOT an operating system.
  33.  
  34. Stop with this. Repeating it makes it not more true. You can load Tiny
  35. Pascal (I didn't port it, so you have actually some work to do), and then
  36. you can compile pascal programs and save them as binaries. You can start 
  37. them up, they will link at load time (just as MS Windows' dynamic linking) 
  38. and they will run. The parameter passing to system routines is a bit 
  39. different from other Pascal compilers, but that's not the point. The 
  40. feature of saving part of the application as binary and reload it later is 
  41. not uniq to my bigFORTH. To the common definition, bigFORTH is just as 
  42. much an operating system as Unix. Unix is NOT a C-only OS, although you 
  43. have to use much of the C environment to start up any program (either C 
  44. hosted or with the C linker /bin/ld linked).
  45.  
  46. Things from Unix missing in bigFORTH: Own file system (there is only a
  47. file interface - but NFS is only an interface, too), no virtual memory
  48. management and some task and network i/o features aren't implemented.
  49. That's not the point. There is even a true NFS from Ewald Rieger who
  50. ports bigFORTH to his 68k microcontroller. bigFORTH boots from any
  51. sequential source, ROM or file, as you like it.
  52.  
  53. The nonexistence of C compilers or so for bigFORTH has it's reason because
  54. bigFORTH isn't a very widespread OS and none of my user needs C programs
  55. hosted by bigFORTH :-).
  56.  
  57. MH>Just go the next logical step and throw away the BLOCK layer.  There's
  58. MH>no reason for it on file-based platforms, and it's continuance
  59. MH>hurts Forth.
  60.  
  61. I have some applications using the BLOCK layer, including the ability to
  62. read stream files. If I cut out the BLOCK layer, no file interface will
  63. work. BLOCKs are the right primitive to implement any sort of disk I/O.
  64. You OS uses blocks, too. Cut it out and try to work ;-).
  65.  
  66. And I never will cut out the primitive under my block layer: It's part of
  67. my memory management that allows to read arbitrary parts of a file as
  68. purgeable memory block. The block layer in between are two one-liners.
  69.  
  70. Some of my files are quite large (the kernal i.e.). I don't want to wait
  71. seconds or more to edit one line in a file. I like structuring programs
  72. into screens - I do so even in stream files. I have a nice editor allowing
  73. both screen- and streamfiles. I think it's a matter of taste and my users
  74. have different tastes. The newer Forth users tend to use stream files, the
  75. elder stay with screen files. I don't want to reduce my market by throwing
  76. things out many users use and like. The market is small enough.
  77.  
  78. MH>It not only saves a tremendous amount of disk space over blocks, but
  79. MH>is still in a format that is interpretable...you don't have to
  80. MH>PKUNZIP it first.
  81.  
  82. I've a 50 MB hard disk. du F:\bigforth gives about 5 MB. This is not
  83. tremendous - one third of this are binaries, GEM resources, dupes and
  84. old projects. Forth sources are so compact, if in screens or streams,
  85. wasting 50% of the space doesn't matter much - projects are still much
  86. shorter than C sources.
  87.  
  88. MH>But with some of the arguments I've witnessed here for BLOCKS, I wouldn't
  89. MH>be surprized if someone proposed coding PKUNZIP in the interpreter to
  90. MH>expand zipped SCEENS for interpretation.
  91.  
  92. :-) One of my users proposed something like this at the last FORTH
  93. Gesellschaft e.V. meeting. He said he'll try to implement it, but I never
  94. heard again ;-).
  95.  
  96. But tell me: why do screens hurt Forth if you can use stream files if you
  97. want? The most unpopular feature of Forth is the postfix notation. Why
  98. don't you start a flame war against this :-). It's realy not difficult to
  99. build an infix compiler for Forth (2 screens - or 32 lines, if you like
  100. that more :-).
  101. -- 
  102. Bernd Paysan
  103. "Late answers are wrong answers!"
  104.