Python 1.6 The balanced language

[Neel Krishnaswami]

Suchandra Thapa <ssthapa at harper.uchicago.edu> wrote:
> Neel Krishnaswami <neelk at brick.cswv.com> wrote:
> >Suchandra Thapa <ssthapa at harper.uchicago.edu> wrote:
> >> 
> >> Actually I think clean is a pure functional oo language.  It's just
> >> that being oo seems to imply that you have some state to your
> >> objects.  Not sure anyone would get around this paradox.
> >
> >No, the distinguishing features of OO are that a) subtyping exists,
> >and b) the types of objects are used to do dynamic dispatch. Mutable
> >state is not necessary -- in both Dylan and Ocaml, it's common to
> >write code in an "object-functional" style, with lots of objects but
> >no mutation.
> 
>     I forgot about the existence of OCaml when I was writing the post
> but ML has imperative features and so is not a pure functional language. 

I usually think of any of the ML/Scheme clan as functional languages,
and specify "pure" when I want to limit myself to Clean or Haskell.

> The example you gave just illustrated dispatch on types. 

Specifically it illustrated dispatch on based on *subtypes*; that is
it looked at the /runtime/ type of the object to decide which method
body to call. So in a typed Python, take the function

def squarelen(lst: List) -> Integer:
    return len(lst) * len(lst)

If you pass squarelen() a SizedList, then it will call the
SizedList.__len__ method, not the List.__len__ method.

> The compiler has no problem determining which to use at compile
> time.  I don't see what requires leaving the choice of len until
> runtime.

We don't know the precise runtime type of the object. In the
squarelen example, all you can tell about the parameter lst is
that it is a List, or an instance of one of its subtypes, like
SizedList.

> Incidentally, what do you mean by dynamic dispatch?  ML and its
> dialect OCaml are statically typed and the compiler chooses which
> function to call at compile time.  Would you consider OCaml to be OO
> then?

The OO extension to Ocaml makes sure that a method exists for every
message send, but it doesn't determine which method to call at compile
time. So no "message not understood" errors can happen, but the
specific method body is chosen based on the runtime type. This is what
I mean by dynamic dispatch. It's a form of overloading constrained by
the type.

> But getting back to OO, I'm not sure how the essentials of OO that
> you put forward mesh with a pure functional approach.  In other
> words suppose I had a method bar belonging to class foo.  How would
> I distinguish using foo.bar from using another function baz that
> took the same parameters and returned the same results?

I'm don't I understand this question.

> It's possible to create such a baz by cutting and pasting the
> function body from bar.  I don't see what using objects gain in this
> context aside from some syntactic sugar.  Also what would the use be
> in declaring two objects of the same class?  They wouldn't behave
> any differently.

Objects with different internal values would behave differently. It's
just that instead of modifying an object we create new ones. Eg,
imagine that every Python object were immutable, like integers and
strings. 


Neel