home *** CD-ROM | disk | FTP | other *** search
/ Programmer's ROM - The Computer Language Library / programmersrom.iso / ada / ai / alsp.cm2 < prev    next >
Encoding:
Text File  |  1988-05-03  |  8.3 KB  |  165 lines
  1.  5-Jun-86 18:18:59-MDT,1410;000000000011
  2. Return-Path: <dritz@anl-mcs.ARPA>
  3. Received: from anl-mcs.ARPA by SIMTEL20.ARPA with TCP; Thu 5 Jun 86 18:18:54-MDT
  4. Received: by anl-mcs.ARPA (4.12/4.9)
  5.     id AA26714; Thu, 5 Jun 86 19:18:26 cdt
  6. Date: Thu, 5 Jun 86 19:18:26 cdt
  7. From: dritz@anl-mcs.ARPA (Kenneth W. Dritz)
  8. Message-Id: <8606060018.AA26714@anl-mcs.ARPA>
  9. To: rconn@simtel20.arpa
  10. Subject: pd:<ada.ai>alspdesgn.doc.1
  11. Cc: dritz@anl-mcs.ARPA
  12.  
  13. Rick,
  14.  
  15. I copied pd:<ada.ai>alsp* to my machine with ftp and then browsed through
  16. the files. The file alspdesgn.doc.1 might as well be omitted, since it
  17. is included as part of alsptech.doc.1 (with a trivial change on the cover
  18. page and in the description of the purpose of the document on page 1). The
  19. latter document is actually a concatenation of two documents, the first of
  20. which is the design specification and the last of which is the final technical
  21. report. Either of two things could be done to eliminate the redundancy:
  22. (1) Delete the former document and leave only the latter, or (2) replace
  23. the latter document by the final technical report "subdocument" contained
  24. in it. The submittors should be consulted to determine if one of these
  25. is acceptable.
  26.  
  27. If I can find a little time, I'll try to compile and execute the source
  28. on the Verdix compiler on our Sequent. If the results are noteworthy, I'll
  29. post them to the net.                  ---Ken Dritz (Dritz @ anl-mcs.arpa)
  30. -------------------------------------------------------------------------
  31. Date: Tue, 1 Sep 87 17:23:27 cdt
  32. From: dritz@anl-mcs.ARPA (Kenneth W. Dritz)
  33. To: rconn@simtel20.arpa
  34. Subject: Comments on PD:<ADA.AI>ALSPTYPES.SRC
  35.  
  36. Over a year ago I submitted a trivial comment about the Lisp/Ada AI types
  37. package (files PD:<ADA.AI>ALSP*).  That comment, which has been stored
  38. in the repository as PD:<ADA.AI>ALSP.CM2, indicated that I would
  39. evaluate the submission, ALSPTYPES.SRC, and comment further once I had
  40. time to do so.  At long last, here it is.
  41.  
  42. Indeed, I compiled and tried to execute the demonstration program
  43. shortly after my previous note.  I encountered several difficulties,
  44. most of which I was able to circumvent.  One, however, was a case of
  45. bad code generation by the compiler I was using, which stopped me
  46. dead.  Our compiler is Sequent's port of the Verdix VADS (Verdix Ada
  47. Development System).  At the time of my first test, the version was 5.2
  48. (or 5.2a).  We have only recently formalized our support agreement with
  49. Verdix and obtained an updated version (5.41) of the VADS.  This
  50. current version corrects the bad-code-generation bug and allows me to
  51. obtain a useful execution of the demonstration program.
  52.  
  53. In short, the circumventable difficulties persist, but once they have
  54. been circumvented execution appears to be normal, or at least as
  55. expected with a very limited number of examples tried.  I'll discuss
  56. the difficulties below.
  57.  
  58. Another commenter has reviewed this same submission (see file
  59. PD:<ADA.AI>ALSP.CMM) and reported no problems of any sort.  Note that
  60. that reviewer tested the submission in the same environment (DEC) in
  61. which the submission was developed, so the fact that no problems were
  62. encountered is not surprising.
  63.  
  64. The first problem is that one of the units of the submission, the
  65. package body for the package named AI_Data_Types, "with"s a package
  66. that is not supplied and not a standard package.  Specifically, it
  67. "with"s Integer_Text_Io.  I assumed that Integer_Text_Io is an
  68. instantiation of Text_Io.Integer_Io for type Integer, and that either
  69. DEC supplies such a pre-instantiated package or the developing
  70. institution maintains one.  My assumption about what Integer_Text_Io
  71. is supposed to be was apparently correct, since with the obvious
  72. circumvention the problem was overcome successfully.  With but one or
  73. two lines of change in the component submitted to the repository, it
  74. would have been more portable.  (I'm guessing that this is a fairly
  75. common problem.)
  76.  
  77. The second problem is somewhat messier.  In several of the units of the
  78. submission, record types with variant parts are declared with variants
  79. like this:
  80.  
  81.             when Var5 => Var5 : String (1 .. 5);
  82.  
  83. Here, the first instance of "Var5" is an enumeration literal of an
  84. enumeration type declared elsewhere, while the second instance of
  85. "Var5" is to be the name of the component declared by the component
  86. declaration contained in the variant.  The VADS interprets the first
  87. instance of Var5 as the name of the component, not the enumeration
  88. literal, and in this context the name of the component is not allowed.
  89. The error diagnostic ("component cannot be used inside its own record")
  90. refers to RM 3.7(3).
  91.  
  92. Since the DEC compiler accepts this, it is possibly a bug in the
  93. Verdix compiler;  alternatively, if the Verdix compiler is correct,
  94. then the DEC compiler is wrong for failing to catch a program error.
  95. After reading the rules for declarative regions and scopes, I am
  96. inclined to believe the DEC compiler is right.  I will submit this to
  97. Verdix and report the results here later.
  98.  
  99. To circumvent this problem I changed the source to use different names
  100. for the enumeration literals and the record components.
  101.  
  102. Although these are the only problems I encountered in testing the
  103. submission, I'd like to comment on something else in the author's
  104. submitted source code and documentation.  In ALSPDESGN.DOC and
  105. ALSPTECH.DOC the author comments that integer overflow (Numeric_Error
  106. exception) during execution, in the DEC system, prevented the
  107. declaration of a "dynamic string" type in the "obvious" way, e.g., as
  108.  
  109.      type Dyn_String (Length : Natural := 80) is
  110.         record
  111.            Dyn_Str : String (1 .. Length);
  112.         end record;
  113.  
  114. The author circumvented this problem by the kludgy technique of
  115. (paraphrasing here;  these are not the names the author used)
  116.  
  117.      type Length_Type is (Var1, Var2, ..., Var15);
  118.      type Dyn_String (Kind : Length_Type := Var1) is
  119.         record
  120.            case Kind is
  121.               when Var1  => Var1  : String (1 .. 1);
  122.               when Var2  => Var2  : String (1 .. 2);
  123.               ...
  124.               when Var15 => Var15 : String (1 .. 15);
  125.            end case;
  126.         end record;
  127.  
  128. which also requires a case statement at each reference to the
  129. component of an object of type Dyn_String (so that the correct
  130. component name can be referenced).  The author's limit of 15 on the
  131. length of "dynamic strings" is probably due to the pain threshold of
  132. extending the above lists beyond 15 elements.  Though I don't know for
  133. sure, the author's original problem in the DEC system may, simply,
  134. have been due to the use of Natural as the subtype of the
  135. discriminant.  I suspect that the DEC system, in elaborating an object
  136. of type Dyn_String (declared according to the original formulation),
  137. reserves storage for an object of the maximum size, which would occur
  138. when the discriminant acquires the value Natural'Last (a pretty big
  139. number).  The integer overflow might have occurred during some kind of
  140. address computation.  (I believe there are implementation techniques
  141. that avoid reserving the maximum storage that might be needed for each
  142. object of the type, by deferring storage allocation and reclamation until
  143. assignment.)  In any case, what the author should have done, I
  144. believe, is decide on a sensible maximum length for dynamic strings,
  145. whether 15 or 80 or 2000, and proceed as follows:
  146.  
  147.      Max_String_Length : constant := 80;
  148.      subtype String_Length is Natural range 1 .. Max_String_Length;
  149.      type Dyn_String (Length : String_Length := 80) is
  150.         record
  151.            Dyn_Str : String (1 .. Length);
  152.         end record;
  153.  
  154. The author did not indicate whether this had been tried.  I am
  155. inclined to believe it would have been successful.  I can tell you
  156. that I have tried it in the Verdix system, and it works as I expected
  157. it to.  (I recall some discussion of this common programming "error"
  158. on the net within the past year.)  With such a change, the source code
  159. of the submission becomes less cumbersome, and the conflict of
  160. names problem I discussed above almost disappears, but not quite
  161. (variant parts are still needed to discriminate between the case of an
  162. integer component and that of a string component of some record type).
  163.  
  164.                                       Ken Dritz  (Dritz @ ANL-MCS.ARPA)
  165.