🚀 go-pugleaf

In article <724312516@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes:

			.................

>I have not seen any posting in which Herman explains *why* he does not
>consider unions an adequate way to specify type punning, despite having
>seen the claim that they *aren't* adequate several times.  (Type coercions
>are something else, in standard usage.)

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.

>In particular, I'll quote an example from message
><723522717@sheol.UUCP>, and I would appreciate it if somebody would
>explain what's so horrible or "inadequate" about the use of unions in
>the example.  I'd especially appreciate comments on the last usage
>below, involving inline functions. 

>-- begin excerpt from <723522717@sheol.UUCP> --
> : Telling the compiler that that number which you used as an integer before
> : is now to be considered a float is not ambiguous, except that most of the
> : current languages will object strongly.

> "Most of the current languages" object strongly because THEY HAVE
> NO SUCH OPERATION.  Herman is simply using an operation that is
> MEANINGLESS IN THE LANGUAGE.

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. 

There was an attempt in the 1930's to introduce a language called
"Basic English" which eliminated most of the verbs in English, as well
as other features.  It never caught on.  Languages should be arbitrarily
extensible.  If humans can conceive of an operation, it should be
possible to add that operation to the language with little problem.
The same holds for types; the C++ classes are really types, and the
C typedef should have been called typealias.  Even prior to C, there
were implementations of Fortran which allowed additional types.

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

> This notation at the use point is not much more clumsy than what Herman
> probably wanted, and is at least meaningful in the language, since care
> was taken to explain to the compiler what was going on.

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.

>-- end excerpt from <723522717@sheol.UUCP> -- 

>While I'm at it, I'd appreciate any explanation for Herman's
>position on "first course" exposure:

>-- begin additional excerpt --
> : Possibly the situation would eventually improve if CS students, in their
> : FIRST course, would be placed in situations where their code would crawl
> : unless they did such things.

> Why should their FIRST course introduce them to situations
> that are strikingly atypical of most software development?

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.  Political correctness is bad
even in political situations.  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?  How many
of them would think of including them?  There are many situations in
which floating point is a guaranteed way to have problems, and the 
person who starts out thinking that the type list of languages such
as C are adequate will have a lot of unlearning to do to be able to
do a good job in those numerous cases where C is inadequate.  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.

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.

> Well, Herman's hope is:

> : This might cause more language producers and hardware designers to
> : realize that there can be large costs with separate integer and floating
> : registers, and that Boolean operations on floating numbers do make sense. 

> It is possible that the cause (ie: early introduction of atypical
> application-specific difficulties) would have this effect (having
> undue attention payed to niche requirements).  It is not clear
> that this is a good thing, however.
>-- end additional excerpt --

Political correctness, again.  There is the standing joke about the
mathematician and the physicist producing hot water.  In the second
case, the mathematician turns things off to reduce to the previous
case.  The CS student, or programmer, who can only think in terms
of the C types, and strict typing, is in this rut.  While mathematicians
do not in fact act this way, these guys are really stuck.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)