Getting started

[James J. Besemer]

Erik Max Francis wrote:

>The problem here is that there is no official "formal definition."  
>

That's a real problem, as a definition for the term was the OP's 
original question.

>Some
>use "weak typing" to mean any type system where the typing can be foiled
>by casts; 
>

The majority of Google references and the one Cardelli reference I was 
able to locate all support this view.  Some of the Google references are 
from University course curriculum, so it's what's being taught to CS 
students.  It's the most authoritative and meaningful definition anyone 
has brought to the table thus far.

>some use it to mean any system where operations, not the
>objects themselves, determine the types of the objects.  
>

By my count, only 2 or 3 people (including yourself), all on this list, 
use this interpretation.  From Google, nobody gave this definition.  The 
only definitions I found contrary to the first alternative was that 
"weak typing" was synonymous with "dynamic typing", which I think 
everybody here rejects.

Furthermore, with elaborate review of the abstractions involved and 
details of the Python implementation, I showed that the above statement 
is really meaningless.  On the one hand, it IS how Python intrinsics are 
implemented internally (operations literally inspect object types, not 
the reverse).  But OTOH it is NOT the abstraction we tend to think of 
when we use the language (objects define operations).  It's one of two 
ways of looking at a language but it's not a way to distinguish one 
language from another.  You have objects and you have operations which 
are associated somehow.  In actuality, neither the object or the 
operation "determines" or makes any decision about anything.  It's the 
runtime environment that glues it all together.  

With user defined types (different implementation than system 
intrinsics), we know there's a dictionary of function names pointed to 
by each object.  But "who" does this lookup?  Who applies the function 
to self (and to self only by convention)?  There's no code in the Object 
to do this.  Nor is there any code in the member function to do the 
lookup.  So, it's not really fair to say that either one "determines" 
what to do, is it?  Else, in which one does the apply() occur?  

In fact, in Python, the answer is none of the above.  It is the 
LOAD_ATTR primitive operator (".") that examines its two arguments 
(faulting if they're not specifically an object reference and a string) 
and then does the dictionary lookup which fetches the resulting 
attribute and pushes it onto the stack.  Then (if the result is a 
function) it's is the CALL_FUNCTION (or a related) operator which looks 
at its arguments on the top of stack and figures out how to proceed 
(primitive function, a method or what?).  So in the end, even Python's 
OOP features are based on (multiple) explicit "operators that have to 
examine the types of its arguments in order to know what operation to 
perform."  But this is in contradiction to how we all "know" objects 
work, so in reality the distinction is meaningless.

>(I favor the
>latter definition, since it carries more information about the
>language.)  
>

It doesn't really tell you anything.  

Else, in 25 words or less, why does Perl's "+" operator supposedly work 
the one way and Python's "*" operator work the other way?

>This is simply a case of differing terminology.
>

In this thread I've been twice accused of, Humpty Dumpty like, using 
terminology of my own device in lieu of some mythical, more 
authoritative source.  And yet many explicit 3rd party references 
(including one of Alex's own) contradicts his interpretation in favor of 
the one I have thus substantiated.  

I dunno -- I tracked down and presented all the references I could find. 
 If the definition I offer from that perspective is not sufficiently 
WORTHY for this group then clearly I have wasted my time.  

You can lead a pig to pearls....

Regards

--jb

-- 
James J. Besemer		503-280-0838 voice
2727 NE Skidmore St.		503-280-0375 fax
Portland, Oregon 97211-6557	mailto:jb at cascade-sys.com
				http://cascade-sys.com