rfc1019.txt

<VC++网络游戏建摸与实现>源代码

   Any particular SMS may have zero, one, or several instances of each
   component type.  The connection between two particular components of
   an SMS, of whatever type, is via Abstract Syntax passed over a "wire"
   joining them.

   1) EDs - Math Editors

   These edit Abstract Syntax to Abstract Syntax.  A particular system
   may have editors that work on some other representations of
   mathematics (e.g., bitmaps, or particular formatting languages),
   however they do not qualify as an ED components of a SMS.  An ED may
   be WYSIWYG or language-oriented.

   2) DISPs - Math Displayers

   These are suites of software packages, device drivers, and hardware
   devices that take in an expr in Abstract Syntax and render it. For
   example, (1) the combination of an Abstract Syntax->TeX translator,
   TeX itself, and a printer, or (2) a plotting package plus a plotting
   device.  A DISP component may or may not support "pointing" (i.e.,
   selection), within an expression it has displayed, fix a printer
   probably doesn't, but terminal screen may. If pointing is supported,
   then a DISP component must be able to pass back the selected
   subexpression(s) in Abstract Syntax. We are not attempting here to
   foresee, or limit, the selection mechanisms that different DISPs may
   offer, but only to require that a DISP be able to communicate its
   selections in Abstract Syntax.

   3) COMPs - Computation systems

   Examples are Numerical Libraries and Computer Algebra systems. There
   are questions as to the state of a COMP component at the time it
   receives an expression. For example, what global flags are set, or
   what previous expressions have been computed that the current
   expression may refer to.  However, we don't delve into these hard
   issues at this time.

   4) DOCs - Document systems

   These are what would typically called "text editors", "document
   editors", or "electronic mail systems".  We are interested in their
   handling of math expressions.  In reality, they manage other document
   constituents as well (e.g., text and graphics).  The design of the
   user interface for the interaction of math, text, and graphics is a
   nontrivial problem, and will doubtless be the subject of further
   research.

   A typical SMS will have an ED and a DISP that are much more closely
   coupled than is suggested here.  For example, the ED's internal
   representation of Abstract Syntax, and the DISP's internal
   representation (e.g., a tree of boxes), may have pointers back and



Arnon                                                           [Page 5]

RFC 1019                                                  September 1987


   forth, or perhaps may even share a common data structure.  This is
   acceptable, but it should always be possible to access the two
   components in the canonical, decoupled way.  For example, the ED
   should be able to receive a standard Abstract Syntax representation
   for an expression, plus an editing command in Abstract Syntax (e.g.,
   Edit[expr, cmd]), and return an Abstract Syntax representation for
   the result.  Similarly, the DISP should be able to receive Abstract
   Syntax over the wire and display it, and if it supports pointing, be
   able to return selected subexpressions in Abstract Syntax.

   The boundaries between the component types are not hard and fast. For
   example, an ED might support simple computations (e.g.,
   simplification, rearrangement of subexpressions, arithmetic), or a
   DOC might contain a facility for displaying mathematical expressions.
   The key thing for a given module to qualify as an SMC is its ability
   to read and write Abstract Syntax.

III. Recommendations and Qualifications

    1. It is our hypothesis that it will be feasible to encode a rich
       variety of other languages in Abstract Syntax, for example,
       programming constructs.  Thus we intend it to be possible to
       pass such things as Lisp formatting programs, plot programs,
       TeX macros, etc. over the wire in Abstract Syntax.  We also
       hypothesize that it will be possible to encode all present and
       future mathematical notations in Abstract Syntax (e.g.,
       commutative diagrams in two or three dimensions).  For
       example, the 3 x 3 identify matrix might be encoded as:

       Matrix[ [1,0,0], [0,1,0], [0,0,1] ]

       while the Abstract Syntax expression:

       Matrix[5, 5, DiagonalRow[1, ThreeDots[], 1],
       BelowDiagonalTriangle[FlexZero[]],
       AboveDiagonalTriangle[FlexZero[]]]

       might encode a 5 x 5 matrix which is to be displayed with a
       "1" in the (1,1) position, a "1" in the (5,5) position, three
       dots between them on the diagonal, a big fat zero in the lower
       triangle indicating the presence of zeros there, and a big fat
       zero in the upper triangle indicating zeros.

    2. We assume the use of the ASCII character set for Abstract Syntax
       expressions.  Greek letters, for example, would need to be
       encoded with expressions like Greek[alpha], or Alpha[].
       Similarly, font encoding is achieved by the use of Abstract
       Syntax such as the following for 12pt bold Times Roman:
       Font[timesRoman, 12, bold, <expression>] Two SMCs are free to
       communicate in a larger character set, or pass font
       specifications in other ways, but they should always be able to



Arnon                                                           [Page 6]

RFC 1019                                                  September 1987


       express themselves in standard Abstract Syntax.

    3. COMPs (e.g., Computer Algebra systems), should be able to
       communicate in Abstract Syntax.  Existing systems should
       have translators to/from Abstract Syntax added to them.  In
       addition, if we can establish a collection of standard names and
       argument lists for common functions, and get all COMP's to read
       and write them, then any Computer Algebra system will be able to
       talk to any other.  Some examples of possible standard names and
       argument lists for common functions:

   Plus[a,b,...]
   Minus[a]
   Minus[a,b]
   Times[a,b,...]
   Divide[<numerator>, <denominator>]
   Power[<base>, <exponent>]
   PartialDerivative[<expr>, <var>]
   Integral[<expr>, <var>, <lowerLimit>,<upperLimit>] (limits optional)
   Summation[<<summand>, <lowerLimit>, <upperLimit>] (limits optional)

      A particular algebra system may read and write nonstandard
      Abstract Syntax.  For example:

   Polynomial[Variables[x, y, z], List[Term[coeff, xExp, yExp, zExp],
   ...

      but, it should be able to translate this to an equivalent standard
      representation. For example:

   Plus[Times[coeff, Power[x, xExp], ...

    4. A DOC must store the Abstract Syntax representations of the
       expressions it contains.  Thus it's easy for it to pass its
       expressions to EDs, COMPs, or DISPs.  A DOC is free to store
       additional expression representations. For example, a tree of
       Boxes, a bitmap, or a TeX description.

    5. DISPs will typically have local databases of formatting
       information.  To actually render the Abstract Syntax, the DISP
       checks for display rules in its database.  If none are found,
       it paints the Abstract Syntax in some standard way.  Local
       formatting databases can be overridden by formatting rules passed
       over the wire, expressed in Abstract Syntax.  It is formatting
       databases that store knowledge of particular display
       environments (for e.g., "typesetting for Journal X").

       The paradigm we wish to follow is that of the genetic code: A
       mathematical expression is like a particular instance of DNA, and
       upon receiving it a DISP consults the appropriate formatting
       database to see if it understands it.  If not, the DISP just



Arnon                                                           [Page 7]

RFC 1019                                                  September 1987


       "passed it through unchanged".  The expression sent over the wire
       may be accompanied by directives or explanatory information,
       which again may or may not be meaningful to a particular DISP.  In
       reality, formatting databases may need to contain Expert
       System-level sophistication to be able to produce professional
       quality typesetting results, but we believe that useful results
       can be achieved even without such sophistication.

    6. With the use of the SMC's specified above, it becomes easy to use
       any DOC as a logging facility for a session with a COMP.  Therefore,
       improvements in DOCs (e.g., browsers, level structuring, active
       documents, audit trails), will automatically give us better
       logging mechanisms for sessions with algebra systems.

    7. Note that Abstract Syntax is human-readable.  Thus any text
       editor can be used as an ED.  Of course, in a typical SMS, users
       should have no need to look at the Abstract Syntax flowing
       through the internal "wires" if they don't care to.  Many will
       want to interact only with mathematics that has a textbook-like
       appearance, and they should be able to do so.

    8. Alan Katz's RFC (cited above) distinguishes the form (i.e.,
       appearance) of a mathematical expression from its content (i.e.,
       meaning, value).  We do not agree that such a distinction can be
       made.  We claim that Abstract Syntax can convey form, meaning,
       or both, and that its interpretation is strictly in the eye
       of the beholder(s).  Meaning is just a handshake between sender
       and recipient.

    9. Help and status queries, the replies to help and status queries,
       and error messages should be read and written by SMC's in
       Abstract Syntax.

   10. In general, it is permissible for two SMC's to use private
       protocols for communication.  Our example of a tightly coupled ED
       and DISP above is one example.  Two instances of a Macsyma COMP
       would be another; they might agree to pass Macsyma internal
       representations back and forth.  To qualify as SMC's, however,
       they should be able to translate all such exchanges into
       equivalent exchanges in Abstract Syntax.














Arnon                                                           [Page 8]