🚀 go-pugleaf

In article <1287@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>There is a heck of a lot of portability which can be achieved, but not in any
>of the current HLLs.  The problem of adding vectors is portable, but the C
>code to do it efficiently on one machine is inefficient on another.  In this
>respect C is too low level.  The same holds for string management.
>
>But C does not handle transfers too well.  There are situations where what is
>wanted is a branch to subroutine, not a subroutine call.  C does not handle
>this at all.  Here C is too high level.  C can do recursion, but not
>coroutines.  And what about a recursion in which one wishes to force
>the use of quantities unchanged in registers?

You seem to have the language C confused with the existing implementations
of C.  Granted, coroutines cannot be expressed in C.  But there is no
reason a C compiler couldn't generate more efficient procedure calls by
using the simpler instructions, or do smart register allocation across
multiple procedures.

Saying "C is inadequate because it leads to inefficient code" is like
saying "Fortran is good because it generates efficient numeric code."
I bet I could write a Fortran compiler that generated awful numeric code!

The Lisp community has understood this difference for years.  As long
as anyone can remember people have been saying "Lisp is slow."  Well,
the MACLISP compiler (on the PDP-10) generated better numeric code than
DEC's Fortran compiler.

Please try not to confuse a language itself (an abstraction, really)
with the implementations you have seen.
-- 
Mike Haertel <mike@stolaf.edu>
main() ??< printf("hello, world??/n"); ??>