🚀 go-pugleaf

:: I have not seen any posting in which Herman explains *why* he does not
:: consider unions an adequate way to specify type punning, [...]

: From: hrubin@pop.stat.purdue.edu (Herman Rubin)
: Message-ID: <Bz9FL2.9rp@mentor.cc.purdue.edu>
: ANYTHING which suggests to the compiler that something is to be stored when
: it does not have to be is not adequate.  Also, there are problems if one
: type of object is, say, 32 bits, and another 64 bits.

First, the problem of 32 bits and 64 bits is completely independent
of the notion of unions.  The exact same problem exists if there is
some sort of value-syntax instead of assignment-syntax type punning.
Therefore, this problem cannot legitimately be blamed on unions.

Second, if the compiler is written with any attention to the C standard,
then the expression (u.i=i,u.f) doesn't really "suggest" that something
is to be stored.  Certainly, none of the compilers I tried this on
actually stored anything.  (Well, I take that back, partly.  They
often stored and then reloaded, or moved to another register, but
that was because they HAD to because of int/float register segregation.)

So, so far, we have as a valid objection that a value-based syntax
is better than an assignment-based syntax.  This is a legitimate,
but rather minimal, objection.

: If a hardware operation, or even a "natural" operation which is somewhat
: more complicated, is not in the language, the language is excessively 
: weak if it cannot be adjoined so as to take into account hardware 
: capability.  The only language I know which has this operation explicitly
: is Galaxy. 

"This operation" (namely, type punning) IS in C and Ada.  Herman just
objects to the "suggestion" of assignment semantics.  As I recall, PL/I
also had type punning.  And finally, aren't both Ada and PL/I's type
punning capabilities value-based rather than assignment-based? (I don't
have my manuals on those two to hand...)

:  [Various excerpts from C, C++, etc. code deletedl]

There were no examples of "C++" or "etc" code.

: The notation is more clumsy, and definitely does not convey the intention.
: The intention is that any moving of the object whose type is being changed
: only occurs if its location does not allow the subsequent actions to be
: taken on the collection of bits.

Herman is apparently seriously claiming that

      g(0xABCD)

is less clumsy and conveys more information than

      g(iasf(0xABCD))

It is essentially impossible to take Herman seriously on this point,
since it is quite obvious that the second case better conveys the
intention.  The first case that Herman claims to prefer actively
CONCEALS the intention.

Note well, I said "the notation at the use point".  And even if I
hadn't, the definition of the iasf function better conveys intent
than actively lying to the compiler.

Again, these points are so simple and so clear that it is
remarkable indeed to have anyone capable of reading and writing
disagree with them as Herman has.   And so I remark upon it.

: This is a chicken-and-egg phenomenon.  Most software development does
: not do certain things because the languages, compilers, and the training
: of the programmers does not mention them.  

That doesn't answer the question.  Herman specifically requested that
students be exposed to situations where code would "really crawl" unless
heroic and often architecture-specific measures are used to optimize it. 
Such cases are extremely rare, whether or not you believe in a catch-22
deadlock between hardware features and language features, or between
developer capabilities and language features. 

: What proportion of current programmers,
: even those who have had "advanced" courses, are aware of the important
: mathematical types of fixed point (NOT integer) and rational?  

Anybody who's been exposed to Lisp and/or PL/I, to name just two
examples.  Since Herman asks about those having had "advanced" courses,
I'd say virtually 100%.  Well...  maybe as few as 90%. 

And if you're really talking mathematics, you're probably dealing
with Mathematica or equivalent notations anyhow, not imperitive
algol-family programming languages.

: Unlearning
: provides major obstacles for students in mathematics and statistics, and
: I see no good reason why CS and programming languages should be any
: different in this matter.

Precisely my point.  CS students under Herman's regime would have
much to unlearn before they could read, write, or even think about
portable, maintainable software.  These issues may not be important
to Herman, but Herman is the exception.

: The student who takes a typical cookbook mathematics course seems to
: be farther away from eventually understanding than the one who starts
: out with the concepts and theory.

But the concepts of and theory of mathematics do not have much to do
with the bit-bumming he recommends early exposure to, so Herman's point
is obscure in the extreme.
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw