home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc5 < prev    next >
Text File  |  1991-04-21  |  26KB  |  950 lines
  1. Network Working Group                        4691
  2. RFC-5                                Jeff Rulifson
  3.                                 June 2, l969
  4.  
  5.  
  6.  
  7.                 DEL
  8.  
  9.  
  10.  
  11. :DEL, 02/06/69 1010:58   JFR   ;   .DSN=1; .LSP=0; ['=] AND NOT SP ; ['?];
  12. dual transmission?
  13.  
  14. ABSTRACT
  15.  
  16.    The Decode-Encode Language (DEL) is a machine independent language
  17.    tailored to two specific computer network tasks:
  18.  
  19.       accepting input codes from interactive consoles, giving immediate
  20.       feedback, and packing the resulting information into message 
  21.       packets for network transmissin.
  22.  
  23.       and accepting message packets from another computer, unpacking
  24.       them, building trees of display information, and sending other
  25.       information to the user at his interactive station.
  26.  
  27.    This is a working document for the evolution of the DEL language.
  28.    Comments should be made through Jeff Rulifson at SRI.
  29.  
  30. FORWARD
  31.  
  32.    The initial ARPA network working group met at SRI on October 25-26,
  33.    1968.
  34.  
  35.       It was generally agreed beforehand that the runmning of interactive
  36.       programs across the network was the first problem that would be
  37.       faced.
  38.  
  39.       This group, already in agreement about the underlaying notions of
  40.       a DEL-like approach, set down some terminology, expectations for
  41.       DEL programs, and lists of proposed semantic capability.
  42.  
  43.       At the meeting were Andrews, Baray, Carr, Crocker, Rulifson, and
  44.       Stoughton.
  45.  
  46.    A second round of meetings was then held in a piecemeal way.
  47.  
  48.       Crocker meet with Rulifson at SRI on November 18, 1968.  This
  49.       resulted in the incorporation of formal co-routines.
  50.  
  51.       and Stoughton meet with Rulifson at SRI on Decembeer 12, 1968.  It
  52.       was decided to meet again, as a group, probably at UTAH, in late
  53.       January 1969.
  54.  
  55.    The first public release of this paper was at the BBN NET meeting in
  56.    Cambridge on February 13, 1969.
  57.  
  58. NET STANDARD TRANSLATORS    
  59.  
  60.    NST   The NST library is the set of programs necessary to mesh
  61.    efficiently with the code compiled at the user sites from the DEL
  62.    programs it receives.  The NST-DEL approach to NET interactive system
  63.    communication is intended to operate over a broad spectrum.
  64.  
  65.    The lowest level of NST-DEL usage is direct transmission to the
  66.    server-host, information in the same format that user programs
  67.    would receive at the user-host.
  68.  
  69.       In this mode, the NST defaults to inaction.  The DEL program
  70.       does not receive universal hardware representation input but 
  71.       input in the normal fashion for the user-host.
  72.  
  73.       And the DEL 1 program becomes merely a message builder and
  74.       sender.
  75.  
  76.    A more intermediate use of NST-DEL is to have echo tables for a
  77.    TTY at the user-host.
  78.  
  79.       In this mode, the DEL program would run a full duplex TTY for
  80.       the user.
  81.  
  82.       It would echo characters, translate them to the character set 
  83.       of the server-host, pack the translated characters in messages,
  84.       and on appropriate break characters send the messages.
  85.  
  86.       When messages come from the server-host, the DEL program would
  87.       translate them to the user-host character set and print them on
  88.       his TTY.
  89.  
  90.    A more ambitious task for DEL is the operation of large,
  91.    display-oriented systems from remote consoles over the NET.
  92.  
  93.       Large interactive systems usually offer a lot of feedback to
  94.       the user.  The unusual nature of the feedback make it
  95.       impossible to model with echo table, and thus a user program
  96.       must be activated in a TSS each time a button state is changed.
  97.  
  98.          This puts an unnecessarily large load on a TSS, and if the
  99.      system is being run through the NET it could easily load two
  100.      systems.
  101.  
  102.      To avoid this double overloading of TSS, a DEL program will
  103.      run on the user-host.  It will handle all the immediate
  104.      feedback, much like a complicated echo table.  At appropriate
  105.      button pushes, message will be sent to the server-host and
  106.      display updates received in return.
  107.  
  108.       One of the more difficult, and often neglected, problems is the
  109.       effective simulation of one nonstandard console on another non-
  110.       standard console.
  111.  
  112.      We attempt to offer a means of solving this problem through
  113.      the co-routine structure of DEL programs.  For the
  114.       complicated interactive systems, part of the DEL programs
  115.      will be constructed by the server-host programmers.
  116.      Interfaces between this program and the input stream may
  117.      easily be inserted by programmers at the user-host site.
  118.  
  119.  
  120. UNIVERSAL HARDWARE REPRESENTATION
  121.  
  122.    To minimize the number of translators needed to map any facility's
  123.    user codes to any other facility, there is a universal hardware
  124.    representation.
  125.  
  126.    This is simply a way of talking, in general terms, about all the
  127.    hardware devices at all the interactive display stations in the initial
  128.    network.
  129.  
  130.    For example, a display is thought of as being a square, the
  131.    mid-point has coordinates (0.0), the range is -1 to 1 on both
  132.    axes.  A point may now be specified to any accuracy, regardless of
  133.    the particular number of density of rastor points on a display.
  134.  
  135.    The representation is discussed in the semantic explanations
  136.    accompanying the formal description of DEL.
  137.  
  138. INTRODUCTION TO THE NETWORK STANDARD TRANSLATOR (NST)
  139.  
  140.    Suppose that a user at a remote site, say Utah, is entered in the
  141.    AHI system and wants to run NLS.
  142.  
  143.    The first step is to enter NLS in the normal way.  At that time
  144.    the Utah system will request a symbolic program from NLS.
  145.  
  146.       REP   This program is written in DEL.  It is called the NLS
  147.       Remote Encode Program (REP).
  148.  
  149.       The program accepts input in the Universal Hardware
  150.       Representation and translates it to a form usable by NLS.
  151.  
  152.       It may pack characters in a buffer, also do some local
  153.       feedback.
  154.  
  155.    When the program is first received at Utah it is compiled and
  156.    loaded to be run in conjunction with a standard library.
  157.  
  158.    All input from the Utah console first goes to the NLS NEP.  It is
  159.    processed, parsed, blocked, translated, etc.  When NEP receives a
  160.    character appropriate to its state it may finally initiate
  161.    transfers to the 940.  The bits transferred are in a form
  162.    acceptable to the 940, and maybe in a standard form so that the
  163.    NLSW need not differentiate between Utah and other NET users.
  164.  
  165.  
  166. ADVANTAGES OF NST
  167.  
  168.    After each node has implemented the library part of the NST, it
  169.    need only write one program for each subsystem, namely the
  170.    symbolic file it sends to each user that maps the NET hardware
  171.    representation into its own special bit formats.
  172.  
  173.       This is the minimum programming that can be expected if 
  174.       console is used to its fullest extent.
  175.  
  176.       Since the NST which runs the encode translation is coded at the
  177.       user site, it can take advantage of hardware at its consoles to
  178.       the fullest extent.  It can also add or remove hardware 
  179.       features without requiring new or different translation tables
  180.       from the host.
  181.  
  182.       Local users are also kept up to date on any changes in the system
  183.       offered at the host site.  As new features are added,
  184.       the host programmers change the symbolic encode program.  When
  185.       this new program is compiled and used at the user site, the new
  186.       features are automatically included.
  187.  
  188.    The advantages of having the encode translation programs
  189.    transferred symbolically should be obvious.
  190.  
  191.       Each site can translate any way it sees fit.  Thus machine code
  192.       for each site can be produced to fit that site; faster run
  193.       times and greater code density will be the result.
  194.  
  195.       Moreover, extra symbolic programs, coded at the user site, may
  196.       be easily interfaced between the user's monitor system and the
  197.       DEL program from the host machine.  This should ease the
  198.       problem of console extension (e.g. accommodating unusual keys and
  199.       buttons) without loss of the flexibility needed for man-machine
  200.       interaction.
  201.  
  202.  
  203.    It is expected that when there is matching hardware, the symbolic
  204.    programs will take this into account and avoid any unnecessary
  205.    computing.  This is immediately possible through the code
  206.    translation constructs of DEL.  It may someday be possible through
  207.    program composition (when Crocker tells us how??)
  208.  
  209.  
  210. AHI NLS - USER CONSOLE COMMUNICATION - AN EXAMPLE
  211.  
  212.    BLOCK DIAGRAM
  213.  
  214.       The right side of the picture represents functions done at the
  215.       user's main computer; the left side represents those done at the
  216.       host computer.
  217.  
  218.      Each label in the picture corresponds to a statement with the
  219.      same name.
  220.  
  221.      There are four trails associated with this picture.  The first
  222.      links (in a forward direction) the labels which are concerned
  223.      only with network information.  The second links the total
  224.      information flow (again in a forward direction).  The last two
  225.      are equivalent to the first two but in a backward direction.
  226.      They may be set with pointers t1 through t4 respectively.
  227.  
  228.      [">tif:] OR I" >nif"]; ["<tif:] OR ["<nif"];
  229.  
  230. USER-TO-HOST TRANSMISSION
  231.  
  232.    Keyboard is the set of input devices at the user's console.
  233.    Input bits from stations, after drifting through levels of monitor
  234.    and interrupt handlers, eventually come to the encode translator.
  235.    [>nif(encode)]
  236.  
  237.    Encode maps the semi-raw input bits into an input stream in a
  238.    form suited to the serving-host subsystem which will process the
  239.    input.  [>nif(hrt)<nif(keyboard)]
  240.  
  241.       The Encode program was supplied by the server-host subsystem
  242.       when the subsystem was first requested.  It is sent to the user
  243.       machine in symbolic form and is compiled at the user machine
  244.       into code particularly suited to that machine.
  245.  
  246.       It may pack to break characters, map multiple characters to
  247.       single characters and vice versa, do character translation, and
  248.       give immediate feedback to the user.
  249.  
  250.    1 dm    Immediate feedback from the encode translator first goes to
  251.    local display management, where it is mapped from the NET standard
  252.    to the local display hardware.
  253.  
  254.       A wide range of echo output may come from the encode
  255.       translator.  Simple character echoes would be a minimum, while
  256.       command and machine-state feedback will be common.
  257.  
  258.       It is reasonable to expect control and feedback functions not
  259.       even done at the server-host user stations to be done in local
  260.       display control.  For example, people with high-speed displays
  261.       may want to selectively clear curves on a Culler display, a
  262.       function which is impossible on a storage tube.
  263.  
  264.    Output from the encode translator for the server-host goes to the
  265.    invisible IMP, is broken into appropriate sizes and labeled by the
  266.    encode translator, and then goes to the NET-to-host translator.
  267.  
  268.       Output from the user may be more than on-line input.  It may be
  269.       larger items such as computer-generated data, or files
  270.       generated and used exclusively at the server-host site but
  271.       stored at the user-host site.
  272.  
  273.       Information of this kind may avoid translation, if it is already in
  274.       server-host format, or it may undergo yet another kind of translation
  275.       if it is a block of data.
  276.  
  277.    hrp  It finally gets to the host, and must then go through the
  278.    host reception program.  This maps and reorders the standard
  279.    transmission-style packets of bits sent by the encode programs
  280.    into messages acceptable to the host.  This program may well be
  281.    part of the monitor of the host machine. [>tif(net mode)<nif(code)]
  282.  
  283.  
  284. HOST-TO-USER TRANSMISSION
  285.  
  286.    decode   Output from the server-host initially goes through decode,
  287.    a translation map similar to, and perhaps more complicated than,
  288.    the encode map.  [>nif(urt)>tif(imp ctrl)<tif(net mode)]
  289.  
  290.       This map at least formats display output into a simplified
  291.       logical-entity output stream, of which meaningful pieces may be
  292.       dealt with in various ways at the user site.
  293.  
  294.      The Decode program was sent to the host machine at the same
  295.      time that the Encode program was sent to the user machine.
  296.      The program is initially in symbolic form and is compiled
  297.      for efficient running at the host machine.
  298.      
  299.      Lines of charaters should be logically identified so that
  300.      different line widths can be handled at the user site.
  301.  
  302.      Some form of logical line identification must also be made.
  303.      For example, if a straight line is to be drawn across the
  304.      display this fact should be transmitted, rather than a
  305.      series of 500 short vectors.
  306.  
  307.      As things firm up, more and more complicated structural
  308.      display information (in the manner of LEAP) should be sent
  309.      and accommodated at user sites so that the responsibility for
  310.      real-time display manipulation may shift closer to the user.
  311.  
  312.       imp ctrl   The server-host may also want to send control
  313.       information to IMPs.  Formatting of this information is done by
  314.       the host decoder.  [>tif(urt) <tif(decode)]
  315.  
  316.       The other control information supplied by the host decoder is
  317.       message break up and identification so that proper assembly and
  318.       sorting can be done at the user site.
  319.  
  320.    From the host decoder, information does to the invisible IMP, and
  321.    directly to the NET-to-user translator.  The only operation done
  322.    on the messages is that they may be shuffled.
  323.  
  324.    urt   The user reception translator accepts messages from the
  325.    user-site IMP 1 and fixes them up for user-site display.  
  326.    [>nif(d ctrl)>tif(prgm ctrl)<tif(imp ctrl)<nif(decode)]
  327.  
  328.       The minimal action is a reordering of the message pieces.
  329.       
  330.       dctrl   For display output, however, more needs to be done.  The
  331.       NET logical display information must be put in the format of
  332.       the user site.  Display control does this job.  Since it
  333.       coordinates between (encode) and (decode) it is able to offer
  334.       features of display management local to the user site.
  335.       [>nif(display)<nif(urt)]
  336.  
  337.       prgmctrl   Another action may be the selective translation and
  338.       routing of information to particular user-site subsystems.
  339.       [>tif(dctrl)<tif(urt)]
  340.  
  341.          For example, blocks of floating-point information may be
  342.      converted to user-style words and sent, in block form, to a
  343.      subsystem for processing or storage.
  344.  
  345.      The styles and translation of this information may well be a 
  346.      compact binary format suitable for quick translation, rather
  347.      than a print-image-oriented format.
  348.  
  349.       (display)   is the output to the user.  [<nif(d ctrl)]
  350.  
  351.    
  352.    USER-TO-HOST INDIRECT TRANSMISSION
  353.  
  354.       (net mode)   This is the mode where a remote user can link to a node
  355.       indirectly through another node.   [<nif(decode)<tif(hrt)]
  356.  
  357.  
  358. DEL SYNTAX
  359.  
  360.    NOTES FOR NLS USERS
  361.   
  362.       All statements in this branch which are not part of the compiler
  363.       must end with a period.
  364.  
  365.       To compile the DEL compiler:
  366.  
  367.      Set this pattern for the content analyzer ( (symbol for up arrow)P1
  368.      SE(P1) <-"-;). The pointer "del" is on the first character of pattern.
  369.  
  370.      Jump to the first statement of the compiler.  The pointer "c"
  371.      is on this statement.
  372.  
  373.      And output the compiler to file  ( '/A-DEL' ).  The pointer "f"
  374.      is on the name of the file for the compiler output -
  375.  
  376.    PROGRAMS
  377.  
  378.       SYNTAX
  379.  
  380.      -meta file (k=100.m=300,n=20,s=900)
  381.  
  382.      file = mesdecl $declaration $procedure "FINISH";
  383.  
  384.      procedure =
  385.  
  386.        procname (
  387.  
  388.           (
  389.  
  390.              type "FUNCTION" /
  391.  
  392.          "PROCEDURE" ) .id (type .id / -empty)) /
  393.  
  394.           "CO-ROUTINE") ' /
  395.  
  396.        $declaration labeledst $(labeledst ';) "endp.";
  397.  
  398.      labeledst = ((left arrow symbol).id ': / .empty) statement;
  399.  
  400.      type = "INTEGER" / "REAL" ;
  401.  
  402.      procname = .id;
  403.  
  404.       Functions are differentiated from procedures to aid compilers in
  405.       better code production and run time checks.
  406.  
  407.      Functions return values.
  408.  
  409.      Procedures do not return values.
  410.  
  411.       Co-routines do not have names or arguments.  Their initial
  412.       envocation points are given the pipe declaration.
  413.  
  414.       It is not clear just how global declarations are to be??
  415.  
  416. DECLARATIONS
  417.  
  418.    SYNTAX
  419.  
  420.       declaration = numbertype / structuredtype / label / lcl2uhr /
  421.       uhr2rmt / pipetype;
  422.  
  423.       numbertype = : ("REAL" / "INTEGER") ("CONSTANT" conlist /
  424.       varlist);
  425.  
  426.       conlist =
  427.  
  428.      .id '(left arrow symbol)constant
  429.  
  430.      $('. .id '(left arrow symbol)constant);
  431.  
  432.       varlist =
  433.  
  434.      .id ('(left arrow symbol)constant / .empty)
  435.  
  436.      $('. .id('(left arrow symbol)constant / .empty));
  437.  
  438.       idlist = .id $('. .id);
  439.  
  440.       structuredtype = (tree" / "pointer" / "buffer" ) idlist;
  441.  
  442.       label = "LABEL1" idlist;
  443.  
  444.       pipetype = PIPE" pairedids $(', pairedids);
  445.  
  446.       pairedids = .id .id;
  447.  
  448.       procname = .id;
  449.  
  450.       integerv = .id;
  451.  
  452.       pipename = .id;
  453.  
  454.       labelv = .id;
  455.  
  456.    Variables which are declared to be constant, may be put in
  457.    read-only memory at run time.
  458.  
  459.    The label declaration is to declare cells which may contain the
  460.    machine addresses of labels in the program as their values.  This 
  461.    is not the B5500 label declaration.
  462.  
  463.    In the pipe declaration the first .ID of each pair is the name of
  464.    the pipe, the second is thke initial starting point for the pipe.
  465.  
  466. ARITHMETIC
  467.  
  468.    SYNTAX
  469.  
  470.       exp = "IF" conjunct "THEN" exp "ELSE" exp;
  471.  
  472.       sum = term (
  473.  
  474.      '+ sum /
  475.  
  476.      '- sum /
  477.  
  478.      -empty);
  479.  
  480.       term = factor (
  481.  
  482.      '* term /
  483.  
  484.      '/ term /
  485.  
  486.      '(up arrow symbol) term /
  487.  
  488.      .empty);
  489.  
  490.       factor = '- factor / bitop;
  491.  
  492.       bitop = compliment (
  493.  
  494.      '/' bitop /
  495.  
  496.      '/'\ bitop /
  497.  
  498.      '& bitop / (
  499.  
  500.      .empty);
  501.  
  502.       compliment = "--" primary / primary;
  503.  
  504.    (symbol for up arrow) means mod. and /\ means exclusive or.
  505.  
  506.    Notice that the uniary minus is allowable, and parsed so you can
  507.    write x*-y.
  508.  
  509.    Since there is no standard convention with bitwise operators, they
  510.    all have the same precedence, and parentheses must be used for
  511.    grouping.
  512.  
  513.    Compliment is the l's compliment.
  514.  
  515.    It is assumed that all arithmetic and bit operations take place in
  516.    the mode and style of the machine running the code.  Anyone who
  517.    takes advantage of word lengths, two's compliment arithmetic, etc.
  518.    will eventually have problems.
  519.  
  520. PRIMARY
  521.  
  522.    SYNTAX
  523.  
  524.       primary =
  525.  
  526.      constant /
  527.  
  528.      builtin /
  529.  
  530.      variable / (
  531.  
  532.      block /
  533.  
  534.      '( exp ');
  535.  
  536.       variable = .id (
  537.  
  538.      '(symbol for left arrow) exp /
  539.  
  540.      '( block ') /
  541.  
  542.      .empty);
  543.  
  544.       constant =  integer / real / string;
  545.  
  546.       builtin =
  547.  
  548.      mesinfo /
  549.  
  550.      cortnin /
  551.  
  552.      ("MIN" / "MAX") exp $('. exp) '/ ;
  553.  
  554.    parenthesized expressions may be a series of expressions.  The
  555.    value of a series is the value of the last one executed at run time.
  556.  
  557.    Subroutines may have one call by name argument.
  558.  
  559.    Expressions may be mixed.  Strings are a big problem?  Rulifson
  560.    also wants to get rid of real numbers!!
  561.  
  562. CONJUNCTIVE EXPRESSION
  563.  
  564.    SYNTAX
  565.  
  566.       conjunct = disjunct ("AND" conjunct / .empty);
  567.  
  568.       disjunct = negation ("OR" negation / .empty);
  569.  
  570.       negation = "NOT" relation / relation;
  571.  
  572.       relation =
  573.  
  574.      '( conjunct ') /
  575.  
  576.      sum (
  577.  
  578.        "<=" sum /
  579.  
  580.        ">=" sum /
  581.  
  582.        '< sum /
  583.  
  584.        '> sum /
  585.  
  586.        '= sum /
  587.  
  588.        '" sum /
  589.  
  590.        .empty);
  591.  
  592.    The conjunct construct is rigged in such a way that a conjunct
  593.    which is not a sum need not have a value, and may be evaluated
  594.    using jumps in the code.  Reference to the conjunct is made only
  595.    in places where a logical decision is called for (e.g. if and
  596.    while statements).
  597.  
  598.    We hope that most compilers will be smart enough to skip
  599.    unnecessary evaluations at run time.  I.e a conjunct in which the
  600.    left part is false or a disjunct with the left part true need not
  601.    have the corresponding right part evaluated.
  602.  
  603. ARITHMETIC EXPRESSION
  604.  
  605.    SYNTAX
  606.  
  607.       statement = conditional / unconditional;
  608.  
  609.       unconditional = loopst / cases / cibtrikst / uist / treest /
  610.       block / null / exp;
  611.  
  612.       conditional = "IF" conjunct "THEN" unconditional (
  613.  
  614.      "ELSE" conditional /
  615.  
  616.      .empty);
  617.  
  618.       block = "begin" exp $('; exp) "end";
  619.  
  620.    An expressions may be a statement.  In conditional statements the
  621.    else part is optional while in expressions it is mandatory.  This
  622.    is a side effect of the way the left part of the syntax rules are
  623.    ordered.
  624.  
  625. SEMI-TREE MANIPULATION AND TESTING
  626.  
  627.    SYNTAX
  628.  
  629.       treest = setpntr / insertpntr / deletepntr;
  630.  
  631.       setpntr = "set" "pointer" pntrname "to" pntrexp;
  632.  
  633.       pntrexp = direction pntrexp / pntrname;
  634.  
  635.       insertpntr = "insert" pntrexp "as"
  636.  
  637.      (("left" / "right") "brother") /
  638.  
  639.      (("first" / "last: ) "daughter") "of" pntrexp;
  640.  
  641.       direction =
  642.  
  643.      "up" /
  644.  
  645.      "down" /
  646.  
  647.      "forward" /
  648.  
  649.      "backward: /
  650.  
  651.      "head" /
  652.  
  653.      "tail";
  654.  
  655.       plantree = "replace" pntrname "with" pntrexp;
  656.  
  657.       deletepntr = "delete: pntrname;
  658.  
  659.       tree = '( tree1 ') ;
  660.  
  661.       tree1 = nodename $nodename ;
  662.  
  663.       nodename = terminal / '( tree1 ');
  664.  
  665.       terminal = treename / buffername / point ername;
  666.  
  667.       treename = id;
  668.  
  669.       treedecl = "pointer" .id / "tree" .id;
  670.  
  671.    Extra parentheses in tree building results in linear subcategorization,
  672.    just as in LISP.
  673.  
  674. FLOW AND CONTROL
  675.  
  676.    controlst = gost / subst / loopstr / casest;
  677.  
  678.    GO TO STATEMENTS
  679.  
  680.       gost = "GO" "TO" (labelv / .id);
  681.  
  682.      assignlabel = "ASSIGN" .id "TO" labelv;
  683.  
  684.    SUBROUTINES
  685.  
  686.       subst = callst / returnst / cortnout;
  687.  
  688.      callst = "CALL" procname (exp / .emptyu);
  689.  
  690.      returnst = "RETURN" (exp / .empty);
  691.  
  692.      cortnout = "STUFF" exp "IN" pipename;
  693.  
  694.       cortnin = "FETCH" pipename;
  695.  
  696.       FETCH is a builtin function whose value is computed by envoking
  697.       the named co-routine.
  698.  
  699.    LOOP STATEMENTS
  700.  
  701.       SYNTAX
  702.  
  703.      loopst = whilest / untilst / forst;
  704.  
  705.      whilest = "WHILE" conjunct "DO" statement;
  706.  
  707.      untilst = "UNTIL" conjunct "DO" statement;
  708.  
  709.      forst = "FOR" integerv '- exp ("BY" exp / .empty) "TO" exp
  710.  
  711.      "DO" statements;
  712.  
  713.       The value of while and until statements is defined to be false
  714.       and true (or 0 and non-zero) respectively.
  715.  
  716.       For statements evaluate their initial exp, by part, and to part
  717.       once, at initialization time.  The running index of for
  718.       statements is not available for change within the loop, it may
  719.       only be read.  If, some compilers can take advantage of this
  720.       (say put it in a register) all the better.  The increment and
  721.       the to bound will both be rounded to integers during the
  722.       initialization.
  723.  
  724. CASE STATEMENTS
  725.  
  726.    SYNTAX
  727.  
  728.       casest = ithcasest / condcasest;
  729.  
  730.       ithcasest = "ITHCASE" exp "OF" "BEGIN" statement $(';
  731.       statement) "END";
  732.  
  733.       condcasest = "CASE" exp "OF" "BEGIN" condcs $('; condcs)
  734.       "OTHERWISE" statement "END";
  735.  
  736.  
  737.       condcs = conjunct ': statement;
  738.  
  739.    The value of a case statement is the value of the last case executed.
  740.  
  741. EXTRA STATEMENTS
  742.  
  743.    null = "NULL";
  744.  
  745. I/O STATEMENTS
  746.  
  747.    iost = messagest / dspyst ;
  748.  
  749.    MESSAGES
  750.  
  751.       SYNTAX
  752.  
  753.          messagest = buildmes / demand;
  754.  
  755.         buildmest = startmes / appendmes / sendmes;
  756.  
  757.           startmes = "start" "message";
  758.  
  759.           appendmes = "append" "message" "byute" exp;
  760.  
  761.           sendmes = "send" "message";
  762.  
  763.           
  764.        demandmes = "demand" "Message";
  765.  
  766.       mesinfo =
  767.  
  768.          "get" "message" "byte"
  769.  
  770.      "message1" "length" /
  771.  
  772.      "message" empty: '?;
  773.  
  774.       mesdecl = "message" "bytes" "are" ,byn "bits" long" '..
  775.  
  776. DISPLAY BUFFERS
  777.  
  778.    SYNTAX
  779.  
  780.       dspyst = startbuffer / bufappend / estab;
  781.  
  782.       startbuffer - "start" "buffer";
  783.  
  784.       bufappend = "append" bufstuff $('& bufstuff);
  785.  
  786.       bufstuff = :
  787.  
  788.      "parameters" dspyparm $('. dspyparm) /
  789.  
  790.      "character" exp /
  791.  
  792.      "string"1 strilng /
  793.  
  794.         "vector" ("from" exp ':exp / .empty) "to" exp '. exp /
  795.  
  796.      "position" (onoff / .empty) "beam" "to" exp '= exp/
  797.  
  798.      curve" ;
  799.  
  800.       dspyparm F :
  801.  
  802.      "intensity" "to" exp /
  803.  
  804.      "character" "width" "to" exp /
  805.  
  806.      "blink" onoff /
  807.  
  808.     "italics" onff;
  809.  
  810.       onoff = "on" / "off";
  811.  
  812.       estab = "establish" buffername;
  813.  
  814.    LOGICAL SCREEN
  815.  
  816.       The screen is taken to be a square.  The coordinates are
  817.       normalized from -1 to +1 on both axes.
  818.  
  819.       Associated with the screen is a position register, called
  820.       PREG.  The register is a triple <x.y.r> where x and y 
  821.       specify a point on the screen and r is a rotation in
  822.       radians, counter clockwise, from the x-axis.
  823.  
  824.       The intensity, called INTENSITY, is a real number in the
  825.       range from 0 to 1.  0 is black, 1 is as light as your
  826.       display can go, and numbers in between specify the relative
  827.       log of the intensity difference.
  828.  
  829.       Character frame size.
  830.  
  831.       Blink bit.
  832.  
  833.    BUFFER BUILDING
  834.  
  835.       The terminal nodes of semi-trees are either semi-tree names
  836.       or display buffers.  A display buffer is a series of logical
  837.       entities, called bufstuff.
  838.  
  839.       When the buffer is initilized, it is empty.  If no
  840.       parameters are initially appended, those in effect at the
  841.       end of the display of the last node in the semi-tree will be in
  842.       effect for the display of this node.
  843.  
  844.       As the buffer is built, the logical entities are added to it.
  845.       When it is established as a buffername, the buffer is
  846.       closed, and further appends are prohibited.  It is only a
  847.       buffername has been established that it may be used in a tree
  848.       building statement.
  849.  
  850.    LOGICAL INPUT DEVICES
  851.  
  852.       Wand
  853.  
  854.       Joy Stick
  855.  
  856.       Keyboard
  857.  
  858.       Buttons
  859.  
  860.       Light Pens
  861.  
  862.       Mice
  863.  
  864.    AUDIO OUTPUT DEVICES
  865.  
  866.    .end
  867.  
  868.  
  869. SAMPLE PROGRAMS
  870.  
  871.    Program to run display and keyboard as tty.
  872.  
  873.    to run NLS
  874.  
  875.       input part
  876.  
  877.       display part
  878.  
  879.      DEMAND MESSAGE;
  880.  
  881.      While LENGTH " O DO
  882.  
  883.         ITHCASE GETBYTE OF Begin
  884.  
  885.         ITHCASE GETBYTE OF %file area uipdate% BEGIN
  886.  
  887.            %literal area%
  888.  
  889.            %message area%
  890.  
  891.            %name area%
  892.  
  893.            %bug%
  894.  
  895.            %sequence specs%
  896.  
  897.            %filter specs%
  898.  
  899.            %format specs%
  900.  
  901.            %command feedback line%
  902.  
  903.            %filer area%
  904.  
  905.            %date time%
  906.  
  907.            %echo register%
  908.  
  909.        BEGIN %DEL control%
  910.  
  911. DISTRIBUTION LIST
  912.  
  913.    Steve Carr
  914.       Department of Computer Science
  915.       University of Utah
  916.       Salt Lake City, Utah  84112
  917.       Phone 801-322-7211 X8224
  918.  
  919.    Steve Crocker
  920.  
  921.       Boelter Hall
  922.       University of California
  923.       Los Angeles, California
  924.       Phone 213-825-4864
  925.  
  926.    Jeff Rulifson
  927.  
  928.       Stanford Research Institute
  929.       333 Ravenswood
  930.       Menlo Park, California  94035
  931.       Phone 415-326-6200 X4116
  932.  
  933.    Ron Stoughton
  934.  
  935.       Computer Research Laboratory
  936.       University of California
  937.       Santa Barbara, California  93106
  938.       Phone 805-961-3221
  939.  
  940.    Mehmet Baray
  941.  
  942.       Corey Hall
  943.       University of California
  944.       Berkeley, California  94720
  945.       Phone 415-843-2621
  946.  
  947.     
  948.  
  949.  
  950.