🚀 go-pugleaf

:: The fact that the language is conceptually
:: stack based does *not* mean that it has *any* stack at runtime!
: From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
: Message-ID: <Bxr9vx.KBD@mentor.cc.purdue.edu>
: This is the case if the considerations for the optimizer were put in by
: the compiler writer.  Computers are extremely fast sub-imbeciles.  If we
: had a group of compiler people who would do their best to incorporate
: considerations which users see in their optimizers, and produce their
: optimizers so that these improvements can be quickly inserted, we may
: get reasonable results.

Yeah, right, it's all those lazy compiler people who just aren't doing
their best.  Just like those lazy statisticians.  If we had a group of
statisticians who would do their best to incorporate the statistical
considerations which users actually see into their statistical models,
and produce their models so that improvements can be quickly inserted,
we might avoid all the misuses of statistics by poor, hard-working,
long-suffering scientists in other fields.

Yeah, right.

: The semantic model of the language can, however, greatly inhibit the
: programmer.  

True.  Just like all those nit-picky details they try to teach in
statistics classes can inhibit a scientist's creativity with numbers. 

: Try communicating floating binary from one machine to
: another; the only semi-portable way I have seen are to convert to
: higher precision floating decimal, transmit that, and convert back.

And this problem is due to the "semantic model of the language?"
Yeah, right.  I'm sure it has nothing to do with the binary format
that the hardware architects of the two machines decided to implement.

::: At the moment, you'd have to hack the Pop compiler to make this generate
::: in-line code. If there was a machine instruction to do the job, I should
::: imagine this might take the compiler-writer, oh, half-an-hour or so. 
: From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
: Message-ID: <Bxpr2J.JF7@mentor.cc.purdue.edu>
: This should be a criticism of the way languages and compilers are produced.
: The user of the language should be able to inline it quickly, with little
: cooperation from the compiler.  And if the compiler-writer has to work so
: hard, the design of the whole thing is atrocious.  

This is simply absurd.  Since it is the compiler's JOB to translate from
a more abstract notation to a more concrete notation, the idea that
changing the way this translation is done is done is feasible "with
little cooperation from the compiler" is, at best, silly. 

I'm aware of compilers in which it would be the work of moments to
insert a new optimization and recognize a new special case.  But if you
really think that a "user" can simply slap in a new optimization
quickly, *without* *breaking* *the* *compiler*, then again, this is at
best, silly. 

The bottom line is, I've worked on compilers and optimizers.  I know at
least some of the problems associated with schemes of allowing users to
specify machine language sequences or new optimizations as part of the
language notation.  To put it simply and bluntly, the problems are not
trivial, and the reasons compiler writers don't often provide such
features are not due to laziness or incompetence.  And I very much doubt
that Herman's insisting on this insulting explanation for so many things
he perceives wrong in compilers is going to be effective in bringing
anybody around to his point of view. 

Now, maybe Herman isn't *intending* to be condescending and insulting. 
But come ON.  "If we had a group of compiler people who would do their
best [..to meet these needs of mine..]" indeed!
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw