Flying With Python (Strong versus Weak Typing)

[Donn Cave]

Quoth alloydflanagan at attbi.com (A. Lloyd Flanagan):
| "Greg Ewing (using news.cis.dfn.de)" <me at privacy.net> wrote in message news:<b4odqg$21u9bt$1 at ID-169208.news.dfncis.de>...
...
|> There are languages with parametric type systems
|> (e.g. Haskell, Eiffel) where it doesn't seem to lead
|> to any of those problems,
|
| You're undoubtedly right.  Still, I now think the notion of type
| should be 'an object which supports these operations', not 'an object
| that inherits from this object (or objects)'.  If I've got an object
| that implements read(), I want to be able to use it in a function that
| calls read() on a parameter, without requiring the object and
| parameter to both inherit from the same class.  You end up doing a lot
| of inheritance, and defining extra interfaces, just to keep the
| compiler happy.

I don't know Eiffel, but in the case of Haskell - if you have a
function that implements read(), you've already done what you need.  
Of course, it will have to be "the" read() function, not just some
function of that name, and you do that with a kind of inheritance.
But it's hard to see that as a major burden.  Here's an example
that declares a "repr" functional class, and then defines it over
a data type.

    class Repr something where
        repr :: something -> String   -- in C notation, String repr(something)

    data Condition = Yes | No | Maybe  -- example data type, like an enum

    instance Repr Condition where
        repr Yes = "Y"
        repr No = "N"
        repr Maybe = "-"

The same data type can also be an instance of other classes as
required.  It doesn't inherit functions from them, it's just
a way of extending the type signature of a function to support
disparate data types.

Well, actually there is a sort of inheritance effect, inasmuch
as it's often enough to just add "deriving Eq" for example to
a data type declaration, to get default functions for comparison.
In the above example, 

    data Condition = Yes | No | Maybe
        deriving Show

would automatically define "show" in a useful way over this
data type.  But my point is that if you have your own "show"
function, you can use it.  The notion of type is just what
you like - 'an object which supports these operations' - and
in a very stringent static type system.

	Donn Cave, donn at u.washington.edu