🚀 go-pugleaf

In article <15941@vail.ICO.ISC.COM>, rcd@ico.ISC.COM (Dick Dunn) writes:
> anw@maths.nott.ac.uk (Dr A. N. Walker) writes:
> . . .
> >    (a)  Is it a language deficiency if "q r <- t/b" cannot be sensibly
> > written?  Answer:  yes...
> 
> This brash conclusion is fair warning that unwarranted generalizations are
> to be found.

Considering that many people have already claimed this to be a deficiency,
the statement that this is a brash conclusion is even more brash.  Since
(except possibly for recent developments) every grade school graduate knew
that a division had a quotient and remainder, why is it brash to require
that this can be sensibly written in a computer language.

> A "deficiency" in a language must be judged in context of the intended use
> of the language.  Therefore a general statement that this is a deficiency
> is wrong...in a language where the need is rare, no deficiency exists.

That someone who cannot see the need for something does not make it reasonable
to call the need rare.  Many others have argued that it is not rare.  And we
have the railroad paradox; if the train will not stop, nobody wanting to use
it will be at the station.

> >    (b)  Should all possible machine-code short-cuts be expressible within
> > the language?  Answer:  yes...
> 
> If you have asm's, you can write lots of machine-code shortcuts assuming
> the hooks are provided to give you access to variables, parameters, etc.
> But this is not "within the language" in any useful sense!  The "asm"
> facility is explicitly an escape from the language.

The asm facility is a massively clumsy escape from the language.  Also, most
compilers make the interface fantastically difficult.  It is generally 
necessary to do massive editing of the assembler output.  Besides, the
assembler notation is almost deliberately designed to make it difficult
for people to use.

And if I am going to use an instruction an appreciable number of times,
why should I not be able to write it in a sensible manner?

> > ...I know of several quite old languages in which the embedded
> > machine code could include expressions, provided that certain restrictions
> > were observed.  Where it matters, there are ways of making this portable.
> 
> The notation can be made quite portable, but the instructions themselves
> cannot.  What's going on here--was this an assertion that we can have
> portable machine language, or only that we can posit a relatively portable
> notation for assembly language?

We can have semi-portable machine language, and extremely flexible notation
not just for assembler instructions, but also for HLL operations not now
included.  A few examples of HLL operations not now expressible conveniently.

The "&~" operation, hardware on many (most?) machines.  Some compilers on some
machines will handle the symbol pair.

The power operator.  Not to be confused with the power function.  The power
operator is highly overloaded.

Unpacking floating point, and the resulting packing.  This frequently requires
an integer type longer than long.

And do it all without loading and storing everything which should stay in
registers.

> >    (c)  Should languages permit "functions with several results"?  Answer:
> > I don't know what the question means, but the answer is yes...
> 
> That does it!  This is complete nonsense!

Possibly he should have said that there is more than one meaning to the
question, but the answer is yes.

A replacement procedure takes the quantities on the right side, performs
the indicated manipulations, and replaces the variables on the left side
by the appropriate values.  There is no specification of the order of the
replacement, that the quantities are in any way to have any more cohesion
than just a list, or that at any time there is to be a single machine
entity (other than scattered registers and memory locations) containing
the results.  So what is so brash about asking for that?

> > ...it's harder to see how the function can be defined sensibly
> > unless the objects are grouped in some way;  but it is clearly a language
> > deficiency if structures and arrays (as well as pointers thereto) cannot be
> > returned from functions.  Many popular languages are defective in this way;
> > some are not.

Well, I do not have this problem.  A list of results is not that hard to
understand.

> Again, per above, it is a deficiency if the facility is needed for the
> intended problem domain of the language.  In many cases being able to
> return a pointer is sufficient, and being able to return an array is at
> odds with other design goals of the language.
> 
> I wish all the would-be language designers would show some more care about
> their suggestions.  It's bad enough that they shoot at a very tiny area of
> the language without a thought for how the pieces will fit together...and
> here, without even a thought for how to solve the tiny target problem.

I wish the designers of the languages would give up the arrogance that they
know everything that the user will want to use.  It is usually very difficult
to add things to a language after the language has been produced, just as it
can be very clumsy to do something in software which could have been cheaply
included in hardware.  I know of no language produced with the idea of even
reasonably efficient code which will allow me to add new operator symbols--
I see now more reason why I should have to write pow(x,y) for x to the y-th
power than you should have to write diff(x,y) for x-y.  Even Fortran found
it necessary to invent an infix notation for that.  And do not tell me to
write that part of my code in Fortran and another part in C.  I may want
to use both constructs in the same expression, and I expect that not to
be unusual.

One can avoid using features of a language which one does not wish to use,
but the opposite is not the case.  Not all primitive operations are 
expressed in the languages.  And because of this, some of these operations
are disappearing from the hardware.  A lot more flexibility is available
for little cost.

I will not be so arrogant as to attempt to tell you everything which should
be in a language.  I do not even know what I might want to use tomorrow.
Languages should be designed by people with this in mind.

> Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
>    ...Simpler is better.

Sometimes.  And what is simpler to you may not be to me.  The order of
pedagogical presentation of mathematics is far from unique, and I assure
you that there is no unanimity on which way is best.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)