What is Expressiveness in a Computer Language

Dimitri Maziuk dima at
Thu Jun 22 18:29:26 CEST 2006

George Neuner sez:
> On Wed, 21 Jun 2006 16:12:48 +0000 (UTC), Dimitri Maziuk
><dima at> wrote:
>>George Neuner sez:
>>> On Mon, 19 Jun 2006 22:02:55 +0000 (UTC), Dimitri Maziuk
>>><dima at> 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
> 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.

Right, but if you look carefully at the paragraph I originally fup'ed
to, you'll notice that it doesn't say "runtime" or "compile-time".
I was commenting on "array bounds not a typing problem" bit -- it is
if you define the index as distinct type, and there is at least one
language that supports it. In this context I don't think it matters
when the check is performed.

It does matter in the larger context of this thread, though. IMO the
important part here is that the crash report clearly points to the
caller code that generated illegal index, not to my library code.

That is the basic argument in favour of compile time error checking,
extended to runtime errors. I don't really care if it's the compiler
or runtime that tells the luser "your code is broken", as long as it
makes it clear it's *his* code that's broken, not mine.

pretty big effort.                                               -- Craig Small

More information about the Python-list mailing list