home *** CD-ROM | disk | FTP | other *** search
/ rtsi.com / 2014.01.www.rtsi.com.tar / www.rtsi.com / OS9 / OSK / APPS / lout2.lzh / LOUT2 / DOC / TR.IMPL / s3.4 < prev    next >
Text File  |  1994-01-25  |  3KB  |  52 lines

  1. @SubSection
  2.     @Tag { defs.impl }
  3.     @Title { Implementation of definitions }
  4. @Begin
  5. @PP
  6. Input is processed by a hybrid parser which employs operator precedence
  7. for objects and simple recursive descent for the headers of
  8. definitions.  A symbol table stores the body of each definition as a
  9. parse tree, except for macros which are lists of tokens, and manages the
  10. usual stack of static scopes, accepting @I PushScope and @I PopScope
  11. operations as the parser enters and leaves scope regions, including
  12. actual body parameters and the right parameter of the @Code "@Open"
  13. operator.
  14. @PP
  15. As the parse proceeds, a complete call graph is constructed, recording,
  16. for each symbol, which symbols are invoked within its body.  Immediately
  17. after the last definition is read, the transitive closure of the call
  18. graph is computed, and used to determine whether each non-parameter
  19. symbol is recursive or receptive (Section {@NumberOf galleys}), and
  20. whether each parameter is invoked exactly once or not.
  21. @PP
  22. Purely functional systems may evaluate symbol invocations in applicative
  23. order (where parameters are evaluated before substitution into bodies),
  24. or in normal order (substitution before evaluation), and they may also
  25. share the value of a parameter among all uses of it.  But in Basser
  26. Lout, the presence of context-sensitive style information (Section
  27. {@NumberOf style}) forces normal order evaluation and prevents sharing
  28. of parameter values.
  29. @PP
  30. To evaluate an unsized object (pure parse tree), its {@I environment},
  31. the equivalent of the stack frames in Algol-like languages, must be
  32. available, containing the actual values of all formal parameters
  33. that are visible within the unsized object.  Environment handling is
  34. a well-known implementation technique, so it will be discussed
  35. only briefly here.
  36. @PP
  37. Environments are extra subtrees hung from the objects they refer
  38. to.  This organization makes excellent use of the ordered dag to
  39. permit environments to be shared, and deleted when the last
  40. reference to them is removed.  Several optimizations have been
  41. implemented.  Actual parameters known to be invoked only once are moved
  42. in from the environment, not copied; copying could lead to quadratic time
  43. complexity.  Actual parameters of the form @Code "@Next" @I object
  44. receive an applicative pre-evaluation which prevents long chains of
  45. @Code "@Next" symbols from forming during the generation of large page
  46. numbers.  Some environments which provably contribute nothing are
  47. deleted, most notably when a symbol invocation has no symbols within its
  48. actual parameters and no import list, so that only the environment of its
  49. body need be kept; this saves a great deal of space when objects with
  50. environments are written to auxiliary files (Section {@NumberOf cross}).
  51. @End @SubSection
  52.