🚀 go-pugleaf

: From: hrubin@pop.stat.purdue.edu (Herman Rubin)
: Message-ID: <BxLyv1.CG4@mentor.cc.purdue.edu>
: I still do not think that this catches the problem.  I did not use des
: for the buffer; des is a short array or struct which contains the global
: information on the location and status of the buffer.

The difference between this and what I presented is trivial.  Simply
have des be a structure containing dope information and a reference to
the buffer, rather than a reference to such a structure.  Or however
else you want to lay it out.

:: You might claim that "reference" (or "ref") is just "pointer" spelled
:: sideways, but there is no "address of" operation, no "indirect"
:: operation, and hence no EXPLICIT pointer operations at all in the
:: language.
: But how does the hardware do it efficiently?  Probably with pointers,
: because the hardware only calls by reference.

This is a change in subject.  The subject was, for several postings
now, to question whether EXPLICIT pointers are required in the
LANGUAGE, not whether some implementation of that language might 
employ pointers.

The notion of "reference" captures the notion of pointer fairly
exactly.  The difference is, it does it implicitly rather than
explicitly, and the indirections needed are explicated at the
definition point instead of at every use point.

How the hardware might best do this is irrelevant to this point.  I
doubt anybody ever seriously claimed that current, practical *hardware*
need not have pointers, any more than anybody in their right mind would
claim that current, practical hardware could/should do without branch
instructions.

At this point, many people may be saying "potAYto, potAHto, I say it's
just equivalent to a pointer!".  But remember, a turing machine
notation is "equivalent" to a lambda calculus, but I wouldn't want to
use the former to reason about computability.  Roman numerals are
"equivalent" arabic notation, but I wouldn't want to do arithmetic 
with the former.  And "reference" notations are better than
"pointer" notations in the specific ways I've already described.


The bottom line is, do you want a notation to describe the abstract,
essential features of the computation you want to do, or a notation to
describe the concrete, incidental features of the computation as
realized on particular hardware?  It is essentially impossible to do
both near-perfectly at the same time.  And from what I understand, the
concrete and incidental features are more important to Herman, because
there is where the last gasp of efficiency is to be had.

Traditionally, such notations are called "assembly languages".
If you need one, you need one, and NO high-level notation is
going to help you.

That said, I'll agree that it is desirable that high-level notations be
able to seamlessly integrate with low-level notations.  For example,
allowing for inline insertion of assembly instructions.  But this is by
no means a trivial problem, it is inherrently unportable (and thus has
very high cost-per-customer), and simply put, the marketplace doesn't
support such features, because needing to squeeze the last two (or even
ten) percent of speed out of a program is a narrow, niche market.  It
is VERY rare that low-level notations need to be more tightly
integrated than with a procedure-call interface, so it just
doesn't pay vendors to provide this.
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw