🚀 go-pugleaf

In article <Pine.SUN.3.91.951005003000.1000A-100000-100000-100000@lagrange.uwaterloo.ca> Viet-Trung Luu <vluu@lagrange.uwaterloo.ca> writes:
>On 3 Oct 1995, Bob Kitzberger wrote:
>
>> Your C heritage is showing.
>
>You're undoubtedly right. ;-)
>
>> Generally you should NOT specify, nor depend, on the number of bits
>> in an integer.  The number of bits used to represent an object
>> is a very low-level concern, and shouldn't find its way into most code.
>> 
>> Instead, you should be concerned about the RANGE OF POSSIBLE VALUES,
>> and let the compiler map this to the appropriate number of bits,
>> a voltage range ;-) or whatever is most efficient on the platform.
>
>Sure, I agree with that. My question is whether you should always have to 
>declare a range or should you be able to expect a "reasonable" range by 
>default. My assertion that integers should be at least 32 bits wide could 
>be translated to something like "all integers should have, by default, a 
>range of at least +/- 1000000000". It just happens that specifying 32 
>bits is convenient.

It's not convenient on a 24-bit machine (5600x).  There are plenty of DSP
and embedded processors for which 32-bit 'int's would be impractical.

>> In Ada:
>> 
>> 	type Height_in_Feet is range 0 .. 1000;
>> 
>> This does require you to _think_ about what legal values of a type
>> are, but also this avoids the many problems of assuming 8 bits is enough,
>> or an int is enough, etc.  
>
>But... when you're declaring a type, legal values might not be a linear 
>range. What if legal values only included even numbers between 1 and 100 
>and between 200 and 300? Where should a language stop in its ability to 
>check ranges? Or should the programmer be able to write a routine to 
>check whether a variable is legal at any given point (and have it run 
>automatically)? The latter approach has its own problems: efficiency and 
>a chicken-and-egg situation (or should the programmer have to both 
>declare a linear range *and* a verification function?!?).

Something is better than nothing, as long as you dont get a false sense
of security from it.  Im more concerned about boundary behavior, ie what
happens with (2^31)*4/32..  When executed in order, it should really
produce an exception - veriants of C which dont optimize to (2^31)/8
return 0 and go on their merry way...  The simple truth of the matter
is you have to know something about the underlying machine in almost any
language.

>> I would agree that the language should allow you to specify how many
>> bits are required, for those occassions where it really matters.
>> Ada supports this as well:
>> 
>> 	type Device_Reg8 is range 0 .. 255;
>> 	for Device_Reg8'Size use 8;
>
>I wonder that should be necessary to have in a language (I'm not sure on 
>this issue). Or should such things be relegated to libraries 
>(standardized, hopefully)? After all, such things are rarely needed 
>except when writing to standard file formats or when communicating with 
>other machines. (Of course, there's always byte-ordering... should a 
>programming language allow that to be specified?!? :-)

A language for developing such interface libraries to files/network ports
which can cleanly and efficiently express the data types and conversions
would be a good thing.  Making it part of the general language is more
likely to lead to people bringing the endian issue up too far in the
abstraction.  If someone builds such a language, it should also take
care of alignment issues as well :->

>> One major annoyance with C is that you can neither specify a range of
>> legal values, nor can you specify the storage required for an object
>> (an 'int' in this case). 
>
>Agreed. However, if 'int' was standardized as being 32-bit (some say that 
>'long' serves that purpose), it would go a long way to solving those 
>problems. (Note that the problems with 'int' are mainly on MS-DOG 
>machines... where 'int' types are still 16-bit usually.)

ACK!  There are machines where char/short/int/long are 8/16/16/16, 8/32/64/64,
32/32/32/32, 16/16/16/16, etc...  There are also 36-bit machines with 9-bit
characters.  C and C++ have become popular due to the fact that one can write
(with a little care) code which will run on a variety of architectures in
an efficient manner, exploiting whats available, and living with what isnt.
Its too late to make all the world a VAX (though X was a darned good try :-)

Dont forget, UNIX and C grew together on a PDP-11 - a 16-bit machine.

>- Trung

-Steve
-- 
--------------------
When all you own is a hammer, every problem is a nail.  Too
many folks grew up with nothing more than a hammer named U**X...