home *** CD-ROM | disk | FTP | other *** search
/ back2roots/padua / padua.7z / padua / lang / gofer223.lha / doc / ch13 < prev    next >
Encoding:
Text File  |  1992-11-10  |  8.7 KB  |  265 lines
  1.  
  2.  
  3. Introduction to Gofer         13. LAYOUT                                        
  4.  
  5.  
  6. 13. LAYOUT
  7.  
  8. 13.1 Comments
  9. -------------
  10. Comments provide an informal but useful way  of  annotating  a  program
  11. with  a  description  of  its  purpose,  structure   and   development.
  12. Following  the  definition  of  Haskell,  two  styles  of  comment  are
  13. supported by Gofer:
  14.  
  15.   o  A one line comment begins with the  two  characters  "--"  and  is
  16.      terminated at the end of the same line.   Note  that  an  operator
  17.      symbol cannot begin with "--" as  this  will  be  treated  as  the
  18.      beginning of a comment.  It is however possible  to  use  the  two
  19.      characters "--" at any other position within an  operator  symbol.
  20.      Thus a line such as:
  21.  
  22.                            (xs ++ ys) -- xs
  23.  
  24.      includes a comment and will actually be treated as if the line had
  25.      been written:
  26.                                (xs ++ ys)
  27.  
  28.      Whereas the line:
  29.  
  30.                            xs >--> ys >--> zs
  31.  
  32.      does not contain any comments (although it  will  cause  an  error
  33.      unless ">-->" has been defined  using  an  appropriate  infixl  or
  34.      infixr declaration).
  35.  
  36.   o  A nested comment begins with the characters "{-",  ends  with  the
  37.      characters "-}" and may span  any  number  of  lines.   [N.B.  the
  38.      initial "{-" string  cannot  overlap  with  the  terminating  "-}"
  39.      string so that the shortest possible nested comment is "{--}", and
  40.      not "{-}"].  An unterminated nested comment will be treated as  an
  41.      error.
  42.  
  43.      As the name suggests, comments of this kind may be nested so  that
  44.      "{- {- ... -} ... {- ... -} -}" is treated as  a  single  comment.
  45.      This makes nested comments particularly convenient  for  enclosing
  46.      parts  of  a  program  which  may  already  contain  other  nested
  47.      comments.
  48.  
  49. Both kinds of comment may be used in expressions entered directly  into
  50. the Gofer system, or more usually, in files of definitions loaded  into
  51. Gofer.  The two  styles  of  comment  may  be  mixed  within  the  same
  52. expression or program, remembering that the string "--" has no  special
  53. significance within a nested comment and that the strings "{-" and "-}"
  54. have no special significance in a single line comment.  Thus:
  55.  
  56.             [ 2, -- {-                 [ 2, {-
  57.               3, -- -}                   -- -} 3,
  58.               4 ]                        4 ]
  59.  
  60. are both equivalent to the list expression [2,3,4].
  61.  
  62.  
  63.  
  64.                                       57
  65.  
  66.  
  67.  
  68.  
  69. Introduction to Gofer         13.2 The layout rule                              
  70.  
  71.  
  72. 13.2 The layout rule
  73. --------------------
  74. In a tradition dating back at least a quarter of a century to  Landin's
  75. ISWIM family of languages,  most  Gofer  programs  use  indentation  to
  76. indicate the structure of a program.  For example, in a definition such
  77. as:
  78.  
  79.                     f x y = g (x + w)
  80.                             where g u = u + v
  81.                                         where v = u * u
  82.                                   w   = 2 + y
  83.  
  84. it is clear from the layout that the definition of w is intended to  be
  85. local to f rather than to g.  Another example  where  layout  plays  an
  86. important role is in distinguishing the two definitions:
  87.  
  88.          example x y z = a + b       example x y z = a + b
  89.                where a = f x y             where a   = f x
  90.                      b = g z                     y b = g z
  91.  
  92. There are three situations in Gofer where indentation is typically used
  93. to determine the structure of a program:
  94.  
  95.   o  At the top-level of a file of definitions.
  96.  
  97.   o  In a group of local declarations following either of the  keywords
  98.      "let" or "where".
  99.  
  100.   o  In a group of alternatives in a  case  expression,  following  the
  101.      keyword "of".
  102.  
  103. In each case, Gofer actually expects to find a list of  items  enclosed
  104. between braces `{' and `}' with individual  items  separated  from  one
  105. another by semicolons `;'.  However, if the leading brace is not  found
  106. then Gofer uses the layout rule described below to arrange for `{', `}'
  107. and `;' tokens to be  inserted  into  the  input  stream  automatically
  108. according to the indentation of each line.
  109.  
  110. In this way, the first example above will in fact be treated as if the
  111. user had entered:
  112.  
  113.                     f x y = g (x + w)
  114.                             where {g u = u + v
  115.                                          where {v = u * u
  116.                                   }; w   = 2 + y
  117.                     }
  118.  
  119. or, equivalently, just:
  120.  
  121.   f x y = g (x + w) where {g u = u + v where {v = u * u}; w = 2 + y}
  122.  
  123. where the additional punctuation using the `{', `}' and `;'  characters
  124. makes the intended grouping clear, regardless of indentation.
  125.  
  126.  
  127.  
  128.  
  129.  
  130.                                       58
  131.  
  132.  
  133.  
  134.  
  135. Introduction to Gofer         13.2 The layout rule                              
  136.  
  137.  
  138. The layout rule used in Gofer is the same as that of Haskell,  and  can
  139. be described as follows:
  140.  
  141.   o  An opening brace `{' is inserted in front of the  first  token  at
  142.      the beginning of a file or following one of the keywords  "where",
  143.      "let" or "of", unless that token is itself an opening brace.
  144.  
  145.   o  A `;' token is inserted in front the first token in any subsequent
  146.      line with exactly the same indentation as the token  in  front  of
  147.      which the opening brace was inserted.
  148.  
  149.   o  The layout rule ends and a `}' token is inserted in front  of  the
  150.      first token in a subsequent line  whose  indentation  is  strictly
  151.      less than that of the token in front of which  the  opening  brace
  152.      was inserted.
  153.  
  154.   o  A closing brace `}' will also be inserted at any  point  where  an
  155.      otherwise unexpected token is encountered.  This part of the rule
  156.      makes it possible to use expressions such as:
  157.  
  158.                        let a = fact 12 in a+a
  159.  
  160.      without needing to use the layout characters explicitly as in:
  161.  
  162.                       let {a = fact 12} in a+a.
  163.  
  164.   o  Lines containing only whitespace (blanks and tabs) and comments do
  165.      not affect the use of the layout rule.
  166.  
  167.   o  For the purposes of determining the indentation of each line in  a
  168.      file, tab stops are assumed to be placed every 8 characters,  with
  169.      the leftmost tab stop in column 9.  Each tab character inserts one
  170.      or more spaces as necessary to move to the next tab stop.
  171.  
  172.   o  The indentation of the end of file token is zero.
  173.  
  174. The following (rather contrived) program, is based on an example in the
  175. Haskell report [5], and provides an extended example of the use of  the
  176. layout rule.  A file containing the following definitions:
  177.  
  178.     data Stack a = Empty
  179.                  | MkStack a (Stack a)
  180.  
  181.     push    :: a -> Stack a -> Stack a
  182.     push x s = MkStack x s
  183.  
  184.     size  :: Stack a -> Int
  185.     size s = length (stkToList s) where
  186.                stkToList Empty         = []
  187.                stkToList (MkStack x s) = x:xs where xs = stkToList s
  188.  
  189.     pop :: Stack a -> (a, Stack a)
  190.     pop (MkStack x s) = (x, case s of r -> i r where i x = x)
  191.  
  192.     top :: Stack a -> a
  193.     top (MkStack x s) = x
  194.  
  195.  
  196.                                       59
  197.  
  198.  
  199.  
  200.  
  201. Introduction to Gofer         13.2 The layout rule                              
  202.  
  203.  
  204. will be treated by Gofer as if it has been written:
  205.  
  206.     {data Stack a = Empty
  207.                   | MkStack a (Stack a)
  208.  
  209.     ;push    :: a -> Stack a -> Stack a
  210.     ;push x s = MkStack x s
  211.  
  212.     ;size  :: Stack a -> Int
  213.     ;size s = length (stkToList s) where
  214.                {stkToList Empty = []
  215.                ;stkToList (MkStack x s) = x:xs where {xs = stkToList s
  216.  
  217.     }};pop :: Stack a -> (a, Stack a)
  218.     ;pop (MkStack x s) = (x, case s of {r -> i r where {i x = x}})
  219.  
  220.     ;top :: Stack a -> a
  221.     ;top (MkStack x s) = x
  222.     }
  223.  
  224. Note that some of the more sophisticated forms of expression cannot  be
  225. written on a single line (and hence entered  directly  into  the  Gofer
  226. system) without explicit use of the layout characters `{', `}' and `;':
  227.  
  228.     ? len [1..10] where len [] = 0;  len (x:xs) = 1 + len xs
  229.     10
  230.     (81 reductions, 108 cells)
  231.  
  232.     ? f True where f x = case x of True->n where {n=not x}; False->True
  233.     False
  234.     (4 reductions, 11 cells)
  235.  
  236.     ?
  237.  
  238. One situation in which the layout  rule  can  cause  problems  is  with
  239. top-level definitions.  For example, the two lines:
  240.  
  241.    f x  = 1 + x
  242.     g y = 1 - y
  243.  
  244. will be treated as a single line "f x = 1 + x g y = 1 - y", which  will
  245. cause a syntax  error.   This  kind  of  problem  becomes  rather  more
  246. difficult to spot if the two definitions are not on  subsequent  lines,
  247. particularly if they are separated by several lines of  comments.   For
  248. this reason, it is usually a good  idea  to  ensure  that  all  of  the
  249. top-level definitions in a file start in the  same  column  (the  first
  250. column is usually the most convenient).  COBOL and Fortran  programmers
  251. are not likely to find this problem too distressing :-)
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.                                       60
  263.  
  264.  
  265.