What is Expressiveness in a Computer Language

George Neuner gneuner2/ at comcast.net
Wed Jun 21 16:55:55 EDT 2006


On Wed, 21 Jun 2006 16:12:48 +0000 (UTC), Dimitri Maziuk
<dima at 127.0.0.1> wrote:

>George Neuner sez:
>> On Mon, 19 Jun 2006 22:02:55 +0000 (UTC), Dimitri Maziuk
>><dima at 127.0.0.1> wrote:
>>
>>>Yet Another Dan sez:
>>>
>>>... Requiring an array index to be an integer is considered a typing 
>>>> problem because it can be checked based on only the variable itself, 
>>>> whereas checking whether it's in bounds requires knowledge about the array.
>>>
>>>You mean like
>>> subtype MyArrayIndexType is INTEGER 7 .. 11
>>> type MyArrayType is array (MyArrayIndexType) of MyElementType
>>>
>>
>> If the index computation involves wider types it can still produce
>> illegal index values.  The runtime computation of an illegal index
>> value is not prevented by narrowing subtypes and cannot be statically
>> checked.
>
>My vague recollection is that no, it won't unless _you_ explicitly code an
>unchecked type conversion. But it's been a while.


You can't totally prevent it ... if the index computation involves
types having a wider range, frequently the solution is to compute a
wide index value and then narrow it.  But if the wider value is out of
range for the narrow type you have a problem.  

Using the illegal wide value in a checked narrowing conversion will
throw a CONSTRAINT_ERROR exception - it doesn't matter whether you
access the array directly using the wide value or try to assign the
value to a variable of the narrow index type.  Using the wide value
unchecked will access memory beyond the array which is not what you
wanted and may cause a crash. 

The point is really that the checks that prevent these things must be
performed at runtime and can't be prevented by any practical type
analysis performed at compile time.  I'm not a type theorist but my
opinion is that a static type system that could, a priori, prevent the
problem is impossible.

George
--
for email reply remove "/" from address



More information about the Python-list mailing list