home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / forth / 3744 < prev    next >
Encoding:
Text File  |  1993-01-02  |  4.3 KB  |  96 lines
  1. Newsgroups: comp.lang.forth
  2. Path: sparky!uunet!paladin.american.edu!gatech!swrinde!ringer!news
  3. From: braker@ennex5.eng.utsa.edu (Jim Brakefield)
  4. Subject: Re: Forth FAQ Answers: Part 01 (What is Forth?).  (V1.0:01.Jan.93)
  5. Message-ID: <1993Jan2.181428.22141@ringer.cs.utsa.edu>
  6. Keywords: Forth, software metatheory, address space
  7. Sender: news@ringer.cs.utsa.edu
  8. Nntp-Posting-Host: ennex5.eng.utsa.edu
  9. Organization: Univ of Texas at San Antonio
  10. References: <4215.UUL1.3#5129@willett.pgh.pa.us>
  11. Date: Sat, 2 Jan 1993 18:14:28 GMT
  12. Lines: 82
  13.  
  14. In article <4215.UUL1.3#5129@willett.pgh.pa.us>  writes:
  15. > What is Forth?
  16. > 
  17. >  (C) Copyright 1992 by Philip J. Koopman Jr.
  18. >  Original message header:
  19. >     From: koopman+@cs.cmu.edu (Philip Koopman)
  20. >     Summary: HOPL-II Forth language description -- Draft 9/17/92
  21.  
  22. >  The following is a draft description of the Forth
  23. >  programming language.  It will eventually appear as 
  24. >  a preprint for the History of Programming Languages 
  25. >  Conference (HOPL-II) to be held in Boston in April 1993.
  26. >  That conference will feature an excellent paper on the 
  27. >  history of Forth by Rather, Colburn & Moore.
  28. >  Constructive criticism appreciated.
  29.  
  30. >  Forth is both an extensible language and an interactive program 
  31. >  development methodology.  While originally developed for small 
  32. >  embedded control mini- and micro-computers, Forth seems to have 
  33. >  been implemented on every major processor manufactured.  It has 
  34. >  been used in a wide variety of applications, such as spreadsheets, 
  35. >  expert systems, and multi-user databases.
  36. > 
  37. >  At the most superficial level, Forth is an almost-directly executable 
  38. >  high-level language for a stack-based abstract machine.  In its 
  39. >  essential form, the Forth abstract machine has a program counter, 
  40. >  memory, ALU, data evaluation pushdown stack, and subroutine return 
  41. >  address pushdown stack.
  42.  
  43. I wish to comment on Forth as an abstraction of computer programming.
  44. That is: the use of Forth to model other software paradigms.  Granted
  45. Forth is primarily a practical language or tool, I see no harm in also
  46. considering it a theoretical vechicle.
  47.  
  48. I choose Koopman's description of the normal-perception-of-Forth as a
  49. point of departure.  The metatheory goes something like:
  50.     Justification of the architecture
  51.     Properties of the architecture
  52.     Embeddings of other software paradigms
  53.  
  54.     Signal space (Boolean logic, gates, & flip-flops) provide the
  55. material for building computers.  Computers are an actual means of 
  56. evaluating expression trees.  Thus the hardware is arranged to provide
  57. a suitable means for expression evaluation (i.e., computation).
  58.  
  59.     Memory is the means to encode the expression tree and its
  60. run-time support.  Memory is an ordered set of states (memory locations).
  61.  
  62.     The complete expression tree is folded to save memory.  This
  63. folding (factoring) is via recursion (iteration is a specific form of
  64. recursion, i.e., tail recursion).
  65.  
  66.     Given that the expression tree is evaluated sequentially, the
  67. dynamic state information can be ordered into a stack.  However it is
  68. better to provide two stacks: a data stack and a return address stack.  
  69.  
  70.     The return stack is seperate from the data stack in that it 
  71. encodes locations in the expression tree and that it is handy to rewrite 
  72. the expression tree (refactor) as part of the software development process 
  73. (the expression tree does not appear all at once, but must be created
  74. and tested a portion at a time).
  75.  
  76. The above is a minimal statement of a rational for why computers and their
  77. software environments are the way they are.  Several things emerge:
  78.  
  79.  Memory economy leads to recursive expression of software.
  80.  The von-Neuman or sequential evaluation mode leads to evaluation stacks.
  81.  The need to refactor the expression tree leads to seperating the data
  82.   and return stacks.
  83.  
  84. It is a little surprising some of the most "glorious" concepts in computer
  85. science have such humble ancestrey: Recursion is a result of the need to
  86. conserve memory, sequential evaluation favors the stack, and the oldest
  87. debugging kluge in the books, splicing in a modified piece of code via
  88. replacing the code with a subroutine call, leads to seperating the 
  89. evaluation stack into data and return stacks.  (pardon my sinicisum)
  90.  
  91. Anyway, I welcome discussion on the above, terse as it is.
  92.  
  93. James Brakefield, braker@ennex1.eng.utsa.edu
  94. Hopeless Forth theoretician
  95.  
  96.