Getting started

[James J. Besemer]

Alex Martelli wrote:

>$a = "2.3";
>$b = 45;
>print $a+$b;
>
>emitting 47.3 is pretty close to what I consider "weak typing".  
>

I don't see why you call this "weak typing".  In Perl, the "+" operator 
is defined to work with strings or numbers.  It may seem more confusing 
at first if you expect "+" also to be the string concatenation operator, 
which it is not.  In the above example,

    print $a . $b;

will print the string "2.345".

This all is no different in principle from Python's:

    a = 2.3
    b = 45L
    print a + b

and getting 47.3.  The "+" operator is defined for floats and also for 
longs.  Since they're all "numbers" it would seem really strange if they 
did not interact naturally like this.  But fundamentally they're 
distinct types as "type( 2.3 )" and "type( 45L )" illustrate.

Perhaps an even better example is the "*" operator:

        print  2  * 5     # integer x integer -> integer
        print [2] * 5     # list x integer -> list
        print "2" * 5     # string x integer -> string

This all makes sense even though radically different results and result 
types are produced each time.  It's not "weakly typed" but rather 
strong, dynamic typing.  The outcome is completely determined by the 
operator and the types of the operands and there is no way to break the 
rules.  Since we know Python is strongly typed then it follows that your 
Perl example must be also.

Anyway, why should "2" + 5 == "7" be all that much stranger than "2" * 5 
== "22222"?  If the operation is unambiguous and useful what rule would 
it break?  Personally, I think Python would be improved slightly by 
adding this conversion.  It's convenient and there's ample precedent in 
other languages (Awk, Snobol, Icon, Perl, etc.).  But I am sure that 
notion will provoke howls of protest from the True Believers.

There are a lot of reasons why Python is better than Perl but strongly 
vs. weakly typed is not one of them.  I don't see a material difference 
in the "strength," per se, of typing between Perl and Python.  They're 
both "strong" and "dynamic", though Python's type model is better 
thought out, particularly since object/type unification.  

Getting back to the original question, the quintessential example of 
"weak typing" is in old C or Fortran where you can define a function to 
take, say, a string argument but are allowed instead pass in a real or a 
pointer to a struct and get garbled results or even corrupt the program:

    printf( "%s\n", 2.5 );        // possible program fault

Another example is all too familiar to MFC programmers:

    CEdit* edit = (CEdit*)GetDialogItem( ID_FOO );

GetDialogItem() essentially returns a raw pointer.  The programmer is 
required to explicitly cast the pointer into the proper type, the same 
type as the dialog item identified by the numeric ID.  However, if the 
dialog item itself changes, say, from an Edit box to a List box then the 
cast becomes wrong, some operations on edit may fail catestrophically, 
and -- worst of all -- the compiler cannot detect and diagnose this 
error for you.
  
These types of errors are not possible in Python or Perl, which 
illustrates that they're both "strong".  

Curiously, in Python

    print "%s" % 2.5

prints the string "2.5" instead of, say, raising an exception.  So 
there's some small precedent for treating numbers as strings in a string 
"context" even in Python.

I'll go out on a limb and say that most "dynamic typed" languages are 
also "strong" by necessity.  If the user isn't keeping track of the 
types then the system HAS to.  An exception I can think of would be an 
ancient dialect of Lisp where integers also were machine addresses and 
thus callable without restriction.  E.g., if a function name evaluated 
to a number the interpreter performed a subroutine call to that address 
instead of, say, applying a lambda.  It was the mechanism through which 
system builtins were accessed.  However,  nothing prevented a user from 
"calling" an arbitrary integer and leaping off into never never land.  

"Strong typing" (the "static" kind) is also the norm in Pascal and C++. 
 I like to think of strong typing as the norm in ANSI C but there is 
still optional and thus may be considered "weak".  Furthermore, C 
programmers are on the "honor" system across module boundaries, as 
there's no link time checking.  There even are ways to cheat in C++, so 
some might still class it as a "weakly typed" language.  Of course, with 
discipline, it's possible to avoid the pitfalls and always use the 
strong typing facilities of C and with effort enjoy most of the benefit.

>I
>find it very hard to produce substantial, large programs using
>weakly-typed languages. 
>
Given my definition of "weakly typed," I agree it's more difficult than 
in strongly typed languages.

On the other hand, isn't it the case that much of Python is implemented 
in C, which is weakly typed?  So "weakly typed" makes it harder but not 
impossible, at least not for some.

> Python is strongly, albeit dynamically, typed,   
>
FWIW, so is Perl.

>Unfortunately, some seminal material of a few
>decades ago confused terminology (I vaguely remember something
>about it in some early article about Scheme, for example).
>
I think you're right.  I originally learned a different taxonomy for 
many of these concepts.  

--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