Pascal Costanza wrote:
> David Hopwood wrote:
>> Pascal Costanza wrote:
>>> Chris Smith wrote:
>>>
>>>> While this effort to salvage the term "type error" in dynamic
>>>> languages is interesting, I fear it will fail. Either we'll all have
>>>> to admit that "type" in the dynamic sense is a psychological concept
>>>> with no precise technical definition (as was at least hinted by
>>>> Anton's post earlier, whether intentionally or not) or someone is
>>>> going to have to propose a technical meaning that makes sense,
>>>> independently of what is meant by "type" in a static system.
>>>
>>> What about this: You get a type error when the program attempts to
>>> invoke an operation on values that are not appropriate for this
>>> operation.
>>>
>>> Examples: adding numbers to strings; determining the string-length of a
>>> number; applying a function on the wrong number of parameters; applying
>>> a non-function; accessing an array with out-of-bound indexes; etc.
>>
>> This makes essentially all run-time errors (including assertion failures,
>> etc.) "type errors". It is neither consistent with, nor any improvement
>> on, the existing vaguely defined usage.
>
> Nope. This is again a matter of getting the levels right.
>
> Consider division by zero: appropriate arguments for division are
> numbers, including the zero. The dynamic type check will typically not
> check whether the second argument is zero, but will count on the fact
> that the processor will raise an exception one level deeper.
That is an implementation detail. I don't see its relevance to the above
argument at all.
> This is maybe better understandable in user-level code. Consider the
> following class definition:
>
> class Person {
> String name;
> int age;
>
> void buyPorn() {
> if (< this.age 18) throw new AgeRestrictionException();
> ...
> }
> }
>
> The message p.buyPorn() is a perfectly valid message send and will pass
> both static and dynamic type tests (given p is of type Person in the
> static case). However, you will still get a runtime error.
Your definition above was "You get a type error when the program attempts
to invoke an operation on values that are not appropriate for this operation."
this.age, when less than 18, is a value that is inappropriate for the buyPorn()
operation, and so this satisfies your definition of a type error. My point was
that it's difficult to see any kind of program error that would *not* satisfy
this definition.
--
David Hopwood <[EMAIL PROTECTED]>
--
http://mail.python.org/mailman/listinfo/python-list
