home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / modula3 / 1142 < prev    next >
Encoding:
Internet Message Format  |  1993-01-24  |  2.2 KB
  1. Path: sparky!uunet!utcsri!torn!spool.mu.edu!wupost!darwin.sura.net!newsserver.jvnc.net!netnews.upenn.edu!dsinc!ub!csn!teal.csn.org!sullivan
  2. From: sullivan@teal.csn.org (Steve Sullivan)
  3. Newsgroups: comp.lang.modula3
  4. Subject: structural equivalence ==> no referential transparency
  5. Message-ID: <C1DAw0.ILz@csn.org>
  6. Date: 24 Jan 93 16:52:42 GMT
  7. Sender: news@csn.org (news)
  8. Distribution: na
  9. Organization: Colorado SuperNet, Inc.
  10. Lines: 48
  11. Nntp-Posting-Host: teal.csn.org
  12.  
  13.  
  14. In Modula 3, arrays lose all index info when passed to a subprocedure.
  15. For example, an array dimensioned [1:10] becomes [0:9] in a called proc.
  16.  
  17. This is a real lack of referential transparency:
  18. vec[1] means different things, depending on which proc it appears in.
  19. If a caller passed an array and an index value of some element
  20. to a subproc, the index value would be invalid in the subproc.
  21. For example:
  22.  
  23. Main proc:
  24.  avec: ARRAY {1..100} OF LONGREAL;
  25.  ...
  26.  x = subproc( avec, k);
  27.  
  28. subproc( avec, k):
  29.   v = avec[k]         (* will access element k+1 *) 
  30.  
  31. Although Modula 3 does have FIRST and LAST functions, they
  32. seem more like afterthoughts than features:  even if the
  33. above subproc were coded   v = avec[FIRST(avec)-1+k],
  34. the subproc must still know the base of avec (hardcoded as "1").
  35. And in any event "avec[FIRST(avec)-1+k]"
  36. is far less clear to the reader than  "avec[k]".
  37.  
  38. I don't know, but I assume the designers did this:
  39.   1. To further the "structural equivalence" concept:
  40.      that all arrays of reals are identical, whether the indices
  41.      of the arrays ints, or an enumerated set.
  42.   2. To avoid headaches in dealing with enumerated index sets.
  43.  
  44. However, for me their decision
  45. not only invalidates all use of enumerated index sets (they
  46. can't be used in subprocs), but destroys the usefulness of
  47. subprocs for handling arrays of any sort.
  48.  
  49. A better approach, in my mind,
  50. would have been to store a pointer to the definition
  51. of the enumeration with each array whose index set is drawn from it.
  52. That way they would main referential transparency.
  53.  
  54. Does anyone know why the Modula 3 designers created such
  55. an unwieldy definition for array handling?  Is there any
  56. thought of changing it?
  57.  
  58. Steve Sullivan
  59. Grad Student, Dept Computer Science, Univ Colorado Boulder
  60. sullivan@csn.org
  61.