Getting started

[Alex Martelli]

Erik Max Francis wrote:

> "James J. Besemer" wrote:
> 
>> However "lame" or "weak" you may consider this feature to be, it does
>> NOT constitute "weak typing" per the formal definition.  This is
>> simple
>> polymorphism, as you seem to acknowledge, same in Perl as in Python.
> 
> The problem here is that there is no official "formal definition."  Some
> use "weak typing" to mean any type system where the typing can be foiled
> by casts; some use it to mean any system where operations, not the
> objects themselves, determine the types of the objects.  (I favor the
> latter definition, since it carries more information about the
> language.)  This is simply a case of differing terminology.

Bingo -- and I think that if one works through all the references I
gave one will see Cardelli cover all the major issues, though he does
not do so in any single one of them and his exact terminology may
differ from mine, yours, James's, "Some authors'" (e.g. Scheme's R4R :

"""
Scheme has latent as opposed to manifest types. Types are associated with 
values (also called objects) rather than with variables. (Some authors 
refer to languages with latent types as weakly typed or dynamically typed 
languages.) Other languages with latent types are APL, Snobol, and other 
dialects of Lisp. Languages with manifest types (sometimes referred to as 
strongly typed or statically typed languages) include Algol 60, Pascal, and 
C. 
"""

and so on.  I don't think it's all that pragmatically useful to have
a black/white definition for properties, in real life -- it may be
good maths (or at least, much-simpler maths) but "practicality beats
purity".  In geometry, a 2D shape either is or isn't a circle: there
is no "being more circular" or "being less circular" -- it's black
and white.  In real life, we don't really care in most application
for a 1-micron deviation on a shape of 1 meter's diameter -- we can
and do consider it "pretty much a circle" for all practical purposes.
One whose deviation is 10 microns is going to be "less circular"
but still OK for most purposes, etc, etc.

It may be important to know the extent and character of the deviation,
of course.  For example, Java or Eiffel are compile-time type-safe
*EXCEPT* for some covariance issues -- in arrays for Java, in
procedure parameters for Eiffel.  C++ has no covariance issues,
but does have explicit casts, unions, etc.  Fortran has no covariance
nor cast issues, but does give compliant compilers a license to NOT
enforce all checks that would be needed to ensure all language rules
are complied with -- IF you follow all the language rules you're OK,
BUT the fact that your program compiles correctly with a compliant
compiler does NOT give you certainty that the rules are indeed
followed -- in Fortran IV and Fortran 77, procedure parameters,
equivalence statements, and mismatch of common statements for the
same common between separately compiled subprograms, are all points
to check (some compilers can check _some_ rules -- all are indeed
enforceable, at runtime at worst, but Fortran's typical emphasis on
speed means they often aren't).

On the other side of the fence, it's clearly trivial to design
a language which can have no type problems -- just give the language
just one type, period.  It's even easy for the compiler to ensure
that you are indeed using that single type (as it's the only one
you have) wherever it's required (i.e., everywhere).  It's of no
bloody practical use whatsoever, of course.


In practice, we want practically useful definitions of things --
"weak typing" is one, but clearly not the only one.  Eg., in another
post James claimed that standard C has no objects -- something
that will no doubt break Kernighan and Ritchie's hearts, since
they write:
"""
An object is a manipulatable region of storage; an lvalue is 
an expression referring to an object
"""
and so on.  [the issue IS important -- an rvalue *NEED NOT*
"refer to an object" in C, while an lvalue *DOES*].

Clearly, James meant "objects as in OO", but that's not
what I wrote and to which he was vehemently responding -- no
matter, he clearly has his own definition of what "an object"
IS, no matter what one of a language's inventor claims an
object is *in the language he invented*...


Our discipline hijacks many terms of everyday use -- e.g.,
to describe something that is done, or is to be done, in a
generic way, I can't safely call it a process nor a task
nor a routine nor a procedure nor a job nor ... all have
specific technical meanings in some language and/or operating
system, and/or in the literature.

It's easier in Italian -- because most such terms are used
in the English original, therefore most Italian equivalents
are free for their ordinary use.  Similarly in the late
Roman Republic some Latin scholars apparently claimed that
Greek was the only language suited to philosophy -- and
didn't note that Latin *with* embedded Greek phrases was in
fact much better, because technical terms appeared as such
and didn't hijack the everyday, ordinary significance
of the word or phrase.


Alex