home *** CD-ROM | disk | FTP | other *** search
/ Programmer's ROM - The Computer Language Library / programmersrom.iso / ada / ai / alsp.cmm < prev    next >
Encoding:
Text File  |  1988-05-03  |  5.8 KB  |  181 lines
  1.  
  2.  
  3.  
  4.             Comments On 
  5.                   C2 Support Modules (AI)
  6.          by Software Architecture & Engineering, Inc. 
  7.  
  8.                             Tool 13_1
  9.                             May 21, 1986
  10.  
  11. COMPILATION
  12. -----------
  13. No recompilation of C2 Support Modules (AI) has been attempted to date.
  14.  
  15.  
  16.  
  17. EXECUTION
  18. ---------
  19. No execution has been attempted to date.
  20.  
  21.  
  22.  
  23. COMMENT
  24. -------
  25.  
  26. C2 Support Modules (AI) was developed as a precursor effort for the 
  27. WWMCCS Information System (WIS).  An executable version of the tool
  28. has been demonstrated.  However, the tool has not been tested 
  29. since delivery by the vendor.  
  30.  
  31.  
  32.  
  33.                               Comments On
  34.                         C2 Support Modules (AI)
  35.              by Software Architecture & Engineering, Inc.
  36.  
  37.  
  38. by
  39. Mars Gralia
  40. The Johns Hopkins University 
  41. Applied Physics Laboratory
  42. Laurel, Maryland
  43. (301) 953-5509
  44.  
  45. March 26, 1987
  46.  
  47.  
  48. SUMMARY
  49. We have successfully compiled and executed the demonstration program of
  50. the 10 files named PD:<ADA.AI>ALSP*.  We have thumbed through the User's
  51. Manual.  We tried several of the examples; all those available via the
  52. demonstration program worked. 
  53.  
  54. The only problem encountered with this Ada/Lisp package is a minor typo
  55. in the Users Manual (file "alsp user.doc"). 
  56.  
  57.  
  58. REVIEW SCOPE
  59. We have done little more than mentioned above in the summary.  Our
  60. machine is a VAX-8650 Cluster, running Ada version 1.3-34, and VMS
  61. version 4.5.  We spent about a half hour examining the User's Manual
  62. (file name "alsp user.doc").  The "pager" file (name "alsp types.src")
  63. was readily fractionated by Pager, and compiled in the order specified
  64. (in file "alsp read.me").  Linking was uneventful after we discovered
  65. its file name.  The demonstration program (file "ai types demo") behaved
  66. exactly as described. 
  67.  
  68. Even though the primary objective of this package is to provide
  69. Lisp-like functions to a user's Ada program, we have not tried that. 
  70.  
  71. We have examined none of the source code.  The demonstration program
  72. appears complete and robust; perhaps this is indication of high code
  73. quality? 
  74.  
  75.  
  76. BUG REPORT
  77. In the User's Manual (alsp user.doc), on page 52, it gives a
  78. demonstration sequence as:
  79.           -> assert1 ((loves ?x1, ?y1), (friends, ?x1, ?y1))
  80.              (((loves ?x1, ?y1), (friends, ?x1, ?y1)))
  81.           -> assert1 ((wife ?x2, ?y2), (loves, ?x2, ?y2))
  82.              (((loves ?x1, ?y1), (friends, ?x1, ?y1))
  83.               ((wife ?x2, ?y2), (loves, ?x2, ?y2)))
  84.           -> assert1 ((), (wife, Mary, John))
  85.              (((loves ?x1, ?y1), (friends, ?x1, ?y1))
  86.               ((wife ?x2, ?y2), (loves, ?x2, ?y2))
  87.               ((), (wife, Mary, John)))
  88. and so on.
  89.  
  90. The bug is a missing comma in the first two "assert1" lines.  They
  91. should read:
  92.           -> assert1 ((loves, ?x1, ?y1), (friends, ?x1, ?y1))
  93.                 ^
  94.           -> assert1 ((wife, ?x2, ?y2), (loves, ?x2, ?y2))
  95.                ^
  96.  
  97.  
  98. AVAILABLE FILES and Reasonable Reading Order
  99.  
  100. I found this to be the right order to read the files.  I have also taken
  101. the liberty to provide a tiny synopsis of each. 
  102.  
  103. 1.1  Alsp read . me
  104. A table of contents, with some annotation and the compilation order.  It
  105. says there are generic packages and demonstration programs. 
  106.  
  107. 1.2  Alsp user . doc
  108. A pretty decent manual for the user.  It explains how to run the
  109. demonstration programs and the background.  Its formatted.  (The demo
  110. program info is given in section 7.1.  It also gives the compilation
  111. order.)
  112.  
  113. 1.3  Alsp tech . doc
  114. The "top level design spec and final report".  It looks pretty
  115. reasonable.  It explains this was developed for Command and Control
  116. (C2) applications where LISP might be desired. 
  117.  
  118. 1.4  Alsp types . src
  119. The source code, in "Pager" archive format.
  120.  
  121. 1.5  Alsp . abs
  122. This is the full management information ("abstract"): developer (in
  123. full), scheduled completion of 30 Jun 85, and so on. 
  124.  
  125. 1.6  `Comment' Reports
  126.  
  127. 1.6.1  Alsp . cmm
  128. A pro forma remark from the archivist: compilation not attempted.
  129.  
  130. 1.6.2  Alsp . cm2
  131. Another comment: "alsp design.doc.1 is a subset of alsp tech.doc.1; it
  132. should be deleted."  They did not compile it either.
  133.  
  134. 1.7  Garbage
  135.  
  136. 1.7.1  Alsp ren . sub
  137. This looks like a VMS command file the developers accidentally sent to
  138. the archive.  Useless to me. 
  139.  
  140. 1.7.2  Alsp src . dis
  141. It looks like a command file for collecting the pieces of this package
  142. for submission; useless to me. 
  143.  
  144.  
  145. RECOMMENDED TESTS
  146.  
  147. I wish I had time to run additional tests.  (Instead, I'll assign it
  148. to my class!)
  149.  
  150. 2.1  Memory Exhaustion
  151. A nasty characteristic of many Ada implementations is memory,
  152. obtained by the "new" construct, is never reclaimed.  (And that's OK
  153. with the Language Reference Manual!)  This phenomenon has limited
  154. the run-time endurance of several of my programs.  Is it a limit
  155. here, too?
  156.  
  157. A test program might create and delete large numbers of dynamic
  158. s-expressions, probably running for several hours.  If it gets a
  159. "storage exception", we know this package suffers the same
  160. limitation.   Unfortunately, there is no way to know it does *not*,
  161. perhaps very slowly, erode memory until there is nothing left.
  162.  
  163. 2.2  Execution Speed
  164. It would be interesting to get a feel for the execution time of a
  165. program which uses these packages.
  166.  
  167.  
  168. OTHER COMMENTS
  169.  
  170. It would be much more convenient if the authors would also provide
  171. the documentation in "source" form.  That would allow me to
  172. re-format it for my size pages; it would look like a real manual.
  173. Furthermore, I don't care what the formatting language is; its
  174. fairly easy to convert from one to another with any decent editor.
  175. After all, I don't want a fancy technical report, just one whose
  176. page boundaries match the paper.
  177.  
  178. (I would provide the "source" of this file, but there is none.  Its
  179. done with a very primitive "what you see is what you get" formatter.
  180. (Where's old runoff when you need it?))
  181.