🚀 go-pugleaf

In article <Bz9FL2.9rp@mentor.cc.purdue.edu] hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
]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.  

First of all: no compiler is actually going to do that store.
Literally: I would project that there is not one single compiler
(other than undergraduate class projects) that would actually do the
store. So what's the big deal? Ugly syntax. Yes, it's ugly. But that's
what macro processors are for. Get yourself m5 or TXL or even Perl, and
the ugly syntax goes away.

]Also, there are problems if one
]type of object is, say, 32 bits, and another 64 bits.

That's _exactly_ the problem. Programming languages are supposed to be
unambiguous. What happens if the sizes are wrong? What does it mean to
mask a sixty-four bit float into a 32 bit int? That _is_ an ambiguous
operation. If you want to do it, the compiler _should_ force you to go
through the machinery to explain exactly what you mean.

]]-- 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. 

Most applications don't _care_ about hardware capability. 

For most applications, the speed of their compiled code is more than
adequate without worrying about machine level bit-twiddling. The
overwhelming majority of the time, the time that it would take to
hand-optimize a piece of code can't be justified in terms of the speed
difference. What's the point of cutting even 1000 machine cycles
(which is generally _far_ greater than the actual amount that could be
saved) out of a procedure, if the user doesn't notice a delay, and the
program spends most of its time idle, waiting for inputs?


]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.

First of all, natural languages are very different from programming
languages (just ask my poor office-mates, all of whom do NLP). The fact
that something is useful in natural language doesn't mean that it should
be included in programming language. (For example, ambiguity can be used
to create very beautiful poetic images in natural languages, whereas it
creates a mess in programming languages.)

And the _vast_ majority of programming languages allow you to add
_any_ operation to the language that makes sense under the comptuation
model used by the language. It's generally called either a function or
a procedure. (Type punning in Haskell is impossible, because it makes
absolutely no sense in the model of the language. But that's not a bad
thing about Haskell - Haskell is a very fine language for it's
intended domain.)

And if you don't like function/procedure call syntax, you have exactly two
choices: either <a] choose a language that has flexible operator
syntax (like, for instance, Lisp or SML), or <b] use a macro processor
like TXL that will allow you to transform out any operator use into an
equivalent function call. (And if you start up your nonsense about how
"operators are faster than functions", I'm going to get really angry,
because it has been explained to you dozens of times that they
aren't.)

]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.

Oh, come on, Herman. As has been said before: Class, in
Object-oriented languages has a specific meaning, distinct from the
conventional meaning of type, and C++ classes hold to that meaning
precisely. It's an appropriate name, and besides that, IT DOESN'T
REALLY MATTER! 

]]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. 

How often is type punning necessary in production software
development? It doesn't come up in the overwhelming majority of
programming situations. Why in the world should you teach something in
the FIRST COURSE that is useless in anything that the overwhelming
majority of the class will _ever_ do in their careers? Wouldn't it be
smarter to teach them something that they'll all need to know?

] ... 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?

Why is it political correctness? You just go around making these
stupid accusations: justify it. Prove to us that it's useful outside
of your specific problem area. Give me _some_ reason to justify
including your things in my language. I haven't seen a single
convincing reason of why I'd want to add it.


]...  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.

I certainly don't think that the type system of C is adequate - but
then, I don't use C. I tend to use languages like Modula-3, Scheme,
and SML. Their type systems have allowed me to easily do everything
that I've needed. I don't write statistical software packages, so I
don't know what kind of operations you need - and I don't care too
much, because I don't think that there are many people who need the
same things you do.

But try this: post an article to the net, describing _exactly_ what
you need. Learn enough about compilers and languages to u
nambiguously, intelligently describe what it is that will do the job
for you. Explain it without any insulting invective. Be clear, and
provide examples. I'll bet that someone will create it for you. Hell,
if you give me an intelligent, complete, understandable explanation of
what you want, I'll implement it for you!

]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.
]
That's exactly our point. You want us to introduce cookbook techniques
like type-punning in the first semester. We don't want that; we want
to introduce the concepts and the theory, and _then_ let the students
discover the techniques after they understand what they're doing.

]] 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.
]
]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.

It's not political correctness; it's what WORKS, for the overwhelming
majority of applications that any of us ever deal with. You exist in a
tiny little niche, with requirements that are terribly different from
those of the rest of the world. What's good for you is _not_ what will
be good for everyone else. (And, admittedly, what's good for other
application areas isn't good for you. But instead of learning enough
to tell anyone what you need. 

And please, stop holding up C as the classic example of a computer
science language. C is a dreadfully designed language, and hardly what
I'd hold up as a fine example of language design by computer
scientists. Try looking at a language like Modula-3 (if you like
imperative languages) or SML (if you like more functional languages)
to see the applications of principles of CS language design.

	<MC>

-- 
|| Mark Craig Carroll: <MC>     ||"If love remains
|| Univ of Delaware, Dept of CIS|| Though everything is lost
|| Grad Student/Labstaff Hacker || We will pay the price
|| carroll@udel.edu             || But we will not count the cost" -Neil Peart