python improvements (Was: Re: New Language)

[Neel Krishnaswami]

Sorry for the slowness in the response, but I've tried to learn about
OCaml's object system before responding.

Martijn Faassen <m.faassen at vet.uu.nl> wrote:
> Neel Krishnaswami <neelk at brick.cswv.com> wrote:
> > Martijn Faassen <m.faassen at vet.uu.nl> wrote:
> [snip]
> >> What about classes and methods though? If you want to optimize some of
> >> the dispatching it may be pretty helpful to have static typing.
> 
> > Strong typing doesn't help with dispatch elimination except in
> > combination with something like Java's 'final' classes or Dylan's
> > 'sealed' classes, or if you do whole-program analysis (like Cecil's
> > Vortex compiler does). [...you need to know the exact type of an
> > object to eliminate it...]
> 
> Sure, but you could optimize *some* of the dispatching if you did
> know the particular class of an object. 

Right -- the problem is that without some guarantees about the class
hierarchy at compile-time, it's impossible to get this knowledge,
since someone can always write an expression that creates a new
subclass of a class and turns what you thought was the exact class
into a set of classes.

> > I don't know if anyone has written an OO language that supports type
> > inferencing -- I was under the impression that adding subtyping rules
> > to Hindley-Milner type systems made them undecidable.
> 
> Hm, I don't know much about ocaml, but the language does some type
> inferencing as far as I'm aware, and it supports objects. Perhaps
> someone more knowledgable about it (you? :) could comment.

I have a big problem in that OCaml refuses to compile on my machine;
this is why I haven't played with Vyper very much, darn it. (It's
because of my truly ancient libc; I'm probably going to upgrade my
Linux this weekend and try again.) What follows is based on just
reading the docs and not actually doing any programming -- so be
warned it may not be 100% accurate.

OCaml *can* infer types for objects. However, there are some odd
restrictions on using them polymorphically. For example, if you have a
list of objects of some type, you need to "cast" any object you push
onto the list to its supertype, and then in subsequent code you can't
use any methods that don't exist for that supertype.

So something like the following Python is not easy to do.

  l = []
  l.append('ni')
  l.append(42)
  print l[0][0]  # == 'n'
  print l[1]**2  # == 1764

The limitations are not a problem in practice because they can use
parametric polymorphism where a C++ programmer would use inheritance.

> >> Definitely agreed. (method caching may not always be that easy, though,
> >> given __getattr__ and friends..)
> 
> > True. I wouldn't mind if there were a smaller hammer than __getattr__,
> > though -- usually I want to catch only a few attributes dynamically, 
> > rather than all of them. 
> 
> A nice syntactic hammer for getter/setters might be useful.

If you could write methods named __get_foo__ and __set_foo__ to trap
references to "obj.foo" without trapping anything else, that would be
sweet. It would let you write exactly what you mean, in a way that's
friendly to the programmer and any potential compilers.
 
> The tricky parts are classes that play with their methods, objects that
> change their classes, etc. Perhaps it's possible to catch these special
> cases and have them invalidate the record cache as far as the objects
> in question pertain. 

Oh, this is essential -- you'd need to do it anyway for when
subclasses are created, and adding these cases wouldn't be very much
additional complexity.

> Do I get the ideas right here? I don't have any practical experience
> with this. I wonder how much of a speedup one might get compared to the
> current scheme. If it isn't significant it's not worth it.
> 
> Also there's of course the question whether dealing will all kinds of
> optimization bugs is worth it.
 
This is always the problem with optimization, especially when the
semantics are de-facto defined by a single implementation. JPython
would be a really good thing if only because it helps keep CPython
honest about what's intended and what's an interpreter quirk.

> I tend to do that as well. Still, it would be nice if there was a
> structured interpreter-checked scheme for this.
 
Sure; I just think these things should be part of the development
environment rather than the language definition. Have you seen the
MrSpidey static debugger for the Rice DrScheme implementation? It's an
adjunct to the development environment that identifies potential type
errors in your code, *without* banning it. So you can get the
flexibility of dynamically typed languages *and* the safety of a
strongly-typed one, and make a tradeoff based on your judgement.


Neel