🚀 go-pugleaf

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.

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.

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

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

>    (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!

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

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