cluman._old_ 11 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389
  1. .so clu;clukey r
  2. .so clu;refman insert
  3. .chapter Expressions
  4. .para
  5. An expression in CLU evaluates to an object in the CLU
  6. universe. This object is said to be the result or value
  7. of the expression.
  8. When we refer to the type of an expression, we mean
  9. the type of this object.
  10. The order of evaluation of subexpressions is left
  11. to right. However, users should not depend upon
  12. this ordering to obtain side effects needed in
  13. other parts of the expression.
  14. The following sections describe the different kinds of
  15. expressions.
  16. .section Literals
  17. .para
  18. Integer, real, character, string and boolean
  19. literals are expressions. The correct syntax for
  20. literals is given in section ??.
  21. The type of a literal expression is the
  22. type of the object named by the literal.
  23. In other words, true is of type bool,
  24. "abc" is of type string, etc.
  25. .section Variables
  26. .para
  27. Variables are identifiers which name
  28. objects of a given type.
  29. The scope of a variable is from
  30. the point of declaration to the
  31. end of the smallest enclosing
  32. scoping unit (see section ??
  33. for description of scoping units).
  34. .section "Procedure, operation and iterator names"
  35. .para
  36. Procedure names are identifiers which may
  37. be followed by an optional parameter list.
  38. The syntax for a procedure name expression is
  39. .show
  40. idn lcurly [const lcurly ,const rcurly ] rcurly
  41. .eshow
  42. The scope of the procedure names is global.
  43. The same identifier may not be redeclared
  44. in any other modules.
  45. .para
  46. The type of a procedure name expression is
  47. .show
  48. proctype( lbkt type_spec lcurly , type_spec rcurly rbkt )
  49. lbkt returns rbkt lbkt signals rbkt
  50. .eshow
  51. where 2returns* has the form
  52. .show
  53. returns (type_spec lcurly , type_spec rcurly )
  54. .eshow
  55. and 2signals* has the form
  56. .show
  57. signals (exception lcurly , exception rcurly ).
  58. .eshow
  59. The lists of type_specs correspond in number and typee
  60. to the lists of arguments and return values of
  61. the procedure named in the expression.
  62. Similarly, the exception list corresponds to the exceptions
  63. of the named procedure.
  64. (The syntax for expressions is given in section ??).
  65. .para
  66. Operation names are names of procedures which are
  67. operations of a cluster.
  68. Operation names have the form:
  69. .show
  70. type_spec $ name lcurly [const lcurly , constrcurly ] rcurly
  71. .eshow
  72. 2Names* have no scope.
  73. They must be unique only within a cluster.
  74. The operation name expression always consists of the
  75. name preceded by type_spec $.
  76. .para
  77. The type of an operation name expression is
  78. .show
  79. proctype(lcurly type_spec lcurly , type_specrcurly rcurly )
  80. lbkt returns rbkt
  81. lbkt signals rbkt
  82. .eshow
  83. where returns and signals are as in procedure types.
  84. .para
  85. The form of an iterator name which is part
  86. of a cluster is
  87. .show
  88. type_spec $ name lcurly [ const lcurly , const rcurly ] rcurly
  89. .eshow
  90. If the iterator is not in a cluster,
  91. the form is:
  92. .show
  93. idn lcurly [ const lcurly , const rcurly ] rcurly
  94. .eshow
  95. The type of an iterator name expression is
  96. .show
  97. itertype ( lcurly type_spec lcurly , type_spec rcurly rcurly)
  98. yields (type_spec lcurly , type_spec rcurly )
  99. lcurly signals (exception lcurly , exception rcurly ) rcurly
  100. .eshow
  101. The lists of type_specs correspond to
  102. the argument list and return value list of the iterator named.
  103. The exception list similarly corresponds to the
  104. list of exceptions signalled by the named iterator.
  105. .section Invocations
  106. .para
  107. Invocations of procedures, operations, and iterators
  108. have the form
  109. .show
  110. primary (lbkt expression lcurly , expressionrcurly rbkt )
  111. .eshow
  112. where primary is an expression which evaluates to a procedure
  113. or iterator object.
  114. The expressions are the actual arguments of the invocation.
  115. So
  116. .show
  117. p(x, y)
  118. .br
  119. int $ add (a, b)
  120. .br
  121. int $ from_to_by (low, high, 2)
  122. .eshow
  123. are invocation expressions.
  124. The type of an invocation expression is
  125. the type of the return value.
  126. Iterators may only be invoked in a for staement.
  127. (see section ?? for the explanation of for statements)
  128. .section "Components of compound types"
  129. .para
  130. CLU provides two compound types in the language.
  131. In addition, users may define other compound types.
  132. Simple notations may be used for naming components of any
  133. types with fetch and store operations,
  134. or get and set operations.
  135. .subsection "Fetch and Store"
  136. .para
  137. Any types which have fetch and store operations, including
  138. arrays, can use the following expressions to name elements
  139. of the objects.
  140. .show
  141. primary[expression]
  142. .eshow
  143. This expression is syntacticaly equivalent to:
  144. .show
  145. type_of_primary $ fetch(primary, expression)
  146. .eshow
  147. unless it appears on the left hand side of an assignment,
  148. in which case it translates to:
  149. .show
  150. type_of_primary $ store( primary, expression, expression2)
  151. .eshow
  152. where expression2 is the expression on the right hand side
  153. of the assignment.
  154. In the case of arrays, 2expression*
  155. represents the index of the element being fetched or stored.
  156. Primary evaluates to the array object being accessed.
  157. It is assumed that user-defined types making use of
  158. this notation will follow this convention,
  159. but no check is made to ensure this.
  160. The translation to the expanded form is purely
  161. syntactic.
  162. If the type of 2primary* does not have the appropriate
  163. fetch or store operation, or the number or types of arguments
  164. do not match, a type error will occur during
  165. type checking.
  166. .subsection "Get and Set operations"
  167. .para
  168. There is also a 'syntactic sugaring' for
  169. naming components of records and objects of user-defined
  170. types having get and/or set operations.
  171. The form of these expressions is:
  172. .show
  173. primary.name
  174. .eshow
  175. This is syntactically equivalent to:
  176. .show
  177. type_of_primary $ get_name(primary)
  178. .eshow
  179. Primary must evaluate to an object of
  180. a type with a get_name operation.
  181. Otherwise, a type-checking error
  182. will occur.
  183. If this expression appears on the left
  184. hand side of an assignment, it is instead translated to:
  185. .show
  186. type_of_primary $ set_name(primary,expression)
  187. .eshow
  188. where 2expression* is the expression on the
  189. right hand side of the assignment.
  190. .section "Constructing arrays and records"
  191. .para
  192. Constructors are expressions in CLU which have
  193. been provided to enable users to create and initialize
  194. arrays and records. Constructors are not provided
  195. for user-defined types.
  196. .subsection "Array constructors"
  197. The array constructor has the form
  198. .show
  199. type_spec$[ lbkt index_expression: rbkt
  200. lbkt expression lcurly ,expression rcurly ]
  201. .eshow
  202. Index_expression is an expression which evaluates to an
  203. integer.
  204. The effect of this expression is to create an array
  205. with low bound equal to the value of index_expression,
  206. and the values of the array elements equal to the
  207. expressions in the expression list.
  208. The size of the array is equal to the number of expressions
  209. listed.
  210. 2Type_spec* must be an array type.
  211. .subsection "Record constructors"
  212. The general form of a record constructor is:
  213. .show
  214. type_spec${field{,field}}
  215. .eshow
  216. Type_spec must evaluate to a record type(see section 2)
  217. Field has the form
  218. name{,name}:expression
  219. The effect of this constructor is to create a new object
  220. of type 2type_spec*, and in each component name place the
  221. value of the corresponding expression.
  222. .section "Binary operations"
  223. .para
  224. CLU allows infix notation to be used
  225. as a 'shorthand' for the following binary
  226. operations.
  227. The table shows the infix operators and
  228. the equivalent expanded form for each
  229. binary operation.
  230. The type_spec for each operation is derived from
  231. the type of the first operand.
  232. .show
  233. Infix form Expansion
  234. expr1 ** expr2 type_spec$power(expr1,expr2)
  235. expr1 // expr2 type_spec$mod(expr1, expr2)
  236. expr1 / expr2 type_spec$div(expr1, expr2)
  237. expr1 * expr2 type_spec$mul(expr1, expr2)
  238. expr1 || expr2 type_spec$concat(expr1,expr2)
  239. expr1+expr2 type_spec$add(expr1,expr2)
  240. expr1-expr2 type_spec$sub(expr1,expr2)
  241. expr1<expr2 type_spec$lt(expr1,expr2)
  242. expr1<=expr2 type_spec$le(expr1,expr2)
  243. expr1=expr2 type_spec$equal(expr1,expr2)
  244. expr1>=expr2 type_spec$ge(expr1,expr2)
  245. expr1>expr2 type_spec$gt(expr1,expr2)
  246. expr1~<expr2 ~(expr1<expr2)
  247. expr1~<=expr2 ~(expr1<=expr2)
  248. expr1~=expr2 ~(expr1=expr2)
  249. expr1~>=expr2 ~(expr1>=expr2)
  250. expr1~>expr2 ~(expr1>expr2)
  251. expr1&expr2 type_spec$and(expr1,expr2)
  252. expr1|expr2 type_spec$or(expr1,expr2)
  253. .eshow
  254. CAND and COR
  255. .para
  256. Two other binary infix operators are allowed.
  257. These are the 'conditional and' operator, CAND,
  258. and the 'conditional or' operator, COR.
  259. .show
  260. expression1 CAND expression2
  261. .eshow
  262. is the boolean AND of expression1 and
  263. expression2. However, if expression1 is false, expression2 is never evaluated.
  264. The types of expression1 and expression2 must be boolean.
  265. .show
  266. expression1 COR expression2
  267. .eshow
  268. is the boolean OR of expression1 and expression2,
  269. but expression2 is not evaluated unless expression1 is false.
  270. The type of expression1 and expression2 must be boolean.
  271. .section "Unary Operators"
  272. Syntactic sugars for two unary operations exist.
  273. -expression is equivalent to t$minus(expression)
  274. where t is the type of expression
  275. ~expression is equivalent to t$not(expression)
  276. where t is the type of expression
  277. .section Precedence
  278. .para
  279. When an expression is not fully parenthesized, the
  280. proper nesting of subexpressions might be ambiguous.
  281. The following precedence rules are used to resolve
  282. such ambiguity.
  283. The precedence of each operator is given in the
  284. table below. Higher precedence operations are performed first.
  285. 1expression1 . name* (the sugar for get_name) and
  286. 1expression1[expression2]* (the sugar for fetch(expression1,expression2)
  287. have the highest precedence.
  288. Unary operators have precedence over binary operators.
  289. The precedence for binary operations is as follows:
  290. operator precedence
  291. ** 5
  292. // 4
  293. / 4
  294. * 4
  295. || 3
  296. + 3
  297. - 3
  298. < 2
  299. <= 2
  300. = 2
  301. >= 2
  302. > 2
  303. ~< 2
  304. ~<= 2
  305. ~= 2
  306. ~>= 2
  307. ~> 2
  308. & 1
  309. CAND 1
  310. | 0
  311. COR 0
  312. The order of evaluation for operators of the
  313. same precedence is left to right. However,
  314. depending on this order when using expressions
  315. which have side effects is strongly discouraged.
  316. .section "Conversion Expressions"
  317. .para
  318. There are no implicit type conversions in CLU.
  319. Three conversion expressions exist for doing
  320. explicit conversions. (A conversion statement
  321. for oneof types also exists and will be discussed
  322. in section ??.)
  323. The three conversion expressions are:
  324. .show
  325. up(expression)
  326. down(expression)
  327. force[type_spec](expression)
  328. .eshow
  329. Up and down may only be used within the body of a cluster operation.
  330. Up changes the type of the expression from the representation type
  331. of the cluster to the abstract type.
  332. Down converts the type of the expression
  333. from the abstract type to the representation type.
  334. .para
  335. Force[type_spec] is the name of the procedure
  336. which takes an object of type any
  337. as an argument and converts it to an object
  338. of type 2type_spec*.
  339. The argument must have base type 2type_spec*.