home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / misc / 4045 < prev    next >
Encoding:
Internet Message Format  |  1992-12-16  |  5.2 KB
  1. Path: sparky!uunet!psinntp!dg-rtp!sheol!throopw
  2. From: throopw@sheol.UUCP (Wayne Throop)
  3. Newsgroups: comp.lang.misc
  4. Subject: Re: Safety.  Was: Re: Pointers
  5. Summary: Herman's position still puzzling
  6. Message-ID: <724478076@sheol.UUCP>
  7. Date: 16 Dec 92 02:52:37 GMT
  8. References: <Bz0Iy5.A9K@mentor.cc.purdue.edu> <724312516@sheol.UUCP> <Bz9FL2.9rp@mentor.cc.purdue.edu>
  9. Lines: 109
  10.  
  11. :: I have not seen any posting in which Herman explains *why* he does not
  12. :: consider unions an adequate way to specify type punning, [...]
  13.  
  14. : From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  15. : Message-ID: <Bz9FL2.9rp@mentor.cc.purdue.edu>
  16. : ANYTHING which suggests to the compiler that something is to be stored when
  17. : it does not have to be is not adequate.  Also, there are problems if one
  18. : type of object is, say, 32 bits, and another 64 bits.
  19.  
  20. First, the problem of 32 bits and 64 bits is completely independent
  21. of the notion of unions.  The exact same problem exists if there is
  22. some sort of value-syntax instead of assignment-syntax type punning.
  23. Therefore, this problem cannot legitimately be blamed on unions.
  24.  
  25. Second, if the compiler is written with any attention to the C standard,
  26. then the expression (u.i=i,u.f) doesn't really "suggest" that something
  27. is to be stored.  Certainly, none of the compilers I tried this on
  28. actually stored anything.  (Well, I take that back, partly.  They
  29. often stored and then reloaded, or moved to another register, but
  30. that was because they HAD to because of int/float register segregation.)
  31.  
  32. So, so far, we have as a valid objection that a value-based syntax
  33. is better than an assignment-based syntax.  This is a legitimate,
  34. but rather minimal, objection.
  35.  
  36. : If a hardware operation, or even a "natural" operation which is somewhat
  37. : more complicated, is not in the language, the language is excessively 
  38. : weak if it cannot be adjoined so as to take into account hardware 
  39. : capability.  The only language I know which has this operation explicitly
  40. : is Galaxy. 
  41.  
  42. "This operation" (namely, type punning) IS in C and Ada.  Herman just
  43. objects to the "suggestion" of assignment semantics.  As I recall, PL/I
  44. also had type punning.  And finally, aren't both Ada and PL/I's type
  45. punning capabilities value-based rather than assignment-based? (I don't
  46. have my manuals on those two to hand...)
  47.  
  48. :  [Various excerpts from C, C++, etc. code deletedl]
  49.  
  50. There were no examples of "C++" or "etc" code.
  51.  
  52. : The notation is more clumsy, and definitely does not convey the intention.
  53. : The intention is that any moving of the object whose type is being changed
  54. : only occurs if its location does not allow the subsequent actions to be
  55. : taken on the collection of bits.
  56.  
  57. Herman is apparently seriously claiming that
  58.  
  59.       g(0xABCD)
  60.  
  61. is less clumsy and conveys more information than
  62.  
  63.       g(iasf(0xABCD))
  64.  
  65. It is essentially impossible to take Herman seriously on this point,
  66. since it is quite obvious that the second case better conveys the
  67. intention.  The first case that Herman claims to prefer actively
  68. CONCEALS the intention.
  69.  
  70. Note well, I said "the notation at the use point".  And even if I
  71. hadn't, the definition of the iasf function better conveys intent
  72. than actively lying to the compiler.
  73.  
  74. Again, these points are so simple and so clear that it is
  75. remarkable indeed to have anyone capable of reading and writing
  76. disagree with them as Herman has.   And so I remark upon it.
  77.  
  78. : This is a chicken-and-egg phenomenon.  Most software development does
  79. : not do certain things because the languages, compilers, and the training
  80. : of the programmers does not mention them.  
  81.  
  82. That doesn't answer the question.  Herman specifically requested that
  83. students be exposed to situations where code would "really crawl" unless
  84. heroic and often architecture-specific measures are used to optimize it. 
  85. Such cases are extremely rare, whether or not you believe in a catch-22
  86. deadlock between hardware features and language features, or between
  87. developer capabilities and language features. 
  88.  
  89. : What proportion of current programmers,
  90. : even those who have had "advanced" courses, are aware of the important
  91. : mathematical types of fixed point (NOT integer) and rational?  
  92.  
  93. Anybody who's been exposed to Lisp and/or PL/I, to name just two
  94. examples.  Since Herman asks about those having had "advanced" courses,
  95. I'd say virtually 100%.  Well...  maybe as few as 90%. 
  96.  
  97. And if you're really talking mathematics, you're probably dealing
  98. with Mathematica or equivalent notations anyhow, not imperitive
  99. algol-family programming languages.
  100.  
  101. : Unlearning
  102. : provides major obstacles for students in mathematics and statistics, and
  103. : I see no good reason why CS and programming languages should be any
  104. : different in this matter.
  105.  
  106. Precisely my point.  CS students under Herman's regime would have
  107. much to unlearn before they could read, write, or even think about
  108. portable, maintainable software.  These issues may not be important
  109. to Herman, but Herman is the exception.
  110.  
  111. : The student who takes a typical cookbook mathematics course seems to
  112. : be farther away from eventually understanding than the one who starts
  113. : out with the concepts and theory.
  114.  
  115. But the concepts of and theory of mathematics do not have much to do
  116. with the bit-bumming he recommends early exposure to, so Herman's point
  117. is obscure in the extreme.
  118. --
  119. Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
  120.