terminological obscurity

[Donn Cave]

Quoth Arthur <ajsiegel at optonline.com>:
| On Thu, 27 May 2004 19:30:40 +0200, "Martin v. Löwis"
| <martin at v.loewis.de> wrote:
|>
|> It is very clear to my why he did not say what Donn said - because
|> he thought that the notion of homogenous and heterogenous is obvious
|> to anybody.
...
| ...  That is the second time I was told the
| problem  was *my* capacity to understand what Guido meant.

Well, I'm unable to see such problems in any other terms.  Understanding
is limited by capacity to understand, certainly.

|> He then *also* said something about how static typing might be
|> introduced into Python - but that was about possible static typing,
|> not about the terms "homogenous" and "heterogenous". Even with
|> static typing, it might be possible to declare a list that is
|> statically typed, contains homogenous data, and yet contains
|> objects as different as None and a module. The type of this
|> list might be "list of (NoneType union ModuleType)", better
|> declared as "list of optional ModuleType".

| Donn. who I think we agree, brought some light to this discussion did
| state clearly, I think, that the use of the "homogenous data" (in
| describing for example  None and a module) is bad and misleading
| terminolgy.  Perhaps, because it supports too well a supposition that
| we are only talking in tautologies. What can be said be homogenous
| about such data, outside of the membership in a list?  Donn suggests
| the list is homogenous, even if the data is not, in any meaningful
| sense.  I think I understand that a bit.

Good!  You're too generous, but it's good of you to spell my name right.

| Yet you insist, with a fresh start on all this, on using the
| terminology "homogenous data".

Oh, well.  You knew what he meant, though, didn't you?  Note that
the passage above describes a slightly different homogeneity.
This list still contains a module and a None, but now some
arrangement has been made to give them each the same type, when
before they were of completely disparate types (and still are.)

Well, I'm not really sure what he has in mind there, so there
is some ambiguity for students of homogeneity such as ourselves.
I'm convincing myself though that this type information does
least for practical purposes become a property of the object,
so they are indeed homogeneous considered on their own. In some
way.

In some languages with strong static typing, such as Haskell or
ML, you'd use a parameterized `algebraic' type sort of like

   type option a = Some a | Nothing

This is essentially a wrapper, a package from which you may
retrieve either the actual data type, or `Nothing'.  That
"a" represents an item of the actual type.  The complete
type of the list would be `option ModuleType'.

However it's done, obviously the fun is in the way a program
can use typed expressions.  Given a classic Python idiom, where
the programmer has learned that optmodlist may contain Nones,

   v = optmodlist[i]
   if v is None:
       print i, '(None)'
   else:
       print i, 'Module', v.__name__

A strongly typed language will do just the same thing, but in a
more explicit and rigorous way, under the sanction of the compiler.
Like

   case optmodlist[i]:
       of Nothing:
           print i, '(None)'
       of Some v:
           print i, v.__name__

One of the problems though is how we fit Python's OOP model in here.
List types like `option ModuleType' seem to be restricted to subtype
polymorphism, plus casting to subtypes, which is no fun.  We would
surely not chafe at an `option FileType' that doesn't allow StringIO.
So maybe the whole system needs to come from a really different angle,
possibly having nothing to do with implementation types like FileType,
NoneType, classes, but instead maybe the interface ideas that have
been going around for some time now.  And of course one could want
the contents of a list to conform to a single interface, thus being
homogeneous in yet another sense.

	Donn Cave, donn at drizzle.com