🚀 go-pugleaf

: From: tmb@arolla.idiap.ch (Thomas M. Breuel)
: Message-ID: <TMB.92Nov17181419@arolla.idiap.ch>
: If anything, if you are going for efficiency, the C approach is more
: portable, saying that "int" is whatever is fastest and "long" gives
: you extra bits. "int" essentially used to mean "CPU register size" and
: "long" was largely intended to mean "probably twice CPU registers
: size, which coincidentally is what multiply may give you, unless
: that's too inconvenient". The only problem with this approach was
: that the early C compilers for 32bit machines messed up and didn't
: make "long" 64bits.

It isn't clear that choosing 32 bits for long was a case of "messing up"
at that point.  The "messing up" happened long before that, IMHO, in
that the notion of the int/long distinction inherrently encouraged
users towards ambiguity.

In particular, in addition to meaning "register size" and "twice
register size", they were used for "int = index into memory-sized
things" and "long = index into file-sized things", and "int = counting
chars in strings" and "long = counting lines in files", and other such
distinctions.

Given the existing code base at the time of the 16-bit-cpu to 32-bit-cpu
transition in the "minicomputer" world, it would have been disastrous
to use the "register size" distinction, and make long be 64 bits.
Most code used long to mean "index into a file" or "counting lines
in files" and so on.  The 16-to-32-bit transition simply made the
size of memory comparable to the size of files, and so the choice
of having both int and long be 32 bits, instead of having both
short and int be 32 bits, seems an appropriate one.

So while it was a Good Thing to have a portable name for "an integer
size natural to the machine" and other such, it was a Bad Thing to
make this a language primitive and then encourage everybody to use it
to express other unrelated abstract properties.

I think the "right way" would have been to make the primitive notation
be a range type, and then have certain standard named types in a
standard include file, to address the "whatever's best for this
machine" issue.

: So again, the problem of having machine independent access to machine
: specific features hasn't been solved because it's inherently not
: solvable. With somewhat better conventions, however, we might be able
: to do a little better than we are doing now.

Agreed.  But replacing existing solutions with new, better solutions
is often not economically feasible.  For example, replacing internal
combustion with external combustion or remote combustion or hybrid
systems is not done, not because of perversity or stubbornness, but
because of the economics of the situation.  C's "short/int/long" is
an example of this internal-combustion-engine scenario, as is
Herman Rubin's problems getting the language features he wants.

It's an economic thing.  So the way to make progress is to find
a way to solve the economic problems involved.  The technological
problems are easy by comparison.
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw