Re: Python discussion, anybody?

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Todd" == Todd Rudick <trudick@example.com> writes:

    Todd> The correct OO way to handle events is to specify callbacks,

I don't see how this helps; you either have to type the callback, in
which case every event anywhere in the program is (possibly, depending
on the call graph) liable to provide that type of callback, or you
push the type check to somewhere else.

    Todd> if you insist on something being done at Runtime

I certainly do; not everything, but there are lots of things it is
very inconvenient to try to anticipate at compile time.

    Todd> It'd be nice to have a tool to find these simple mistakes.

The simple mistake in Frederic's question _would_ be found by the
Emacs LISP bytecompiler.  A warning would be issued that a variable
was assigned to but not used.  But you asked for more complex things,
said that wasn't good enough.

More seriously, Python's bytecompiler probably does _not_ issue such
warnings because there would be too many of them.  (I mentioned that
almost nobody ever tries to eliminate byte-compiler warnings, didn't
I?)  One possible strategy would be to use a "similar names" heuristic
to identify possible typos (although my /etc/coda/venus.conf
auto-config'd by Debian has "cachesize" as a typo for "cacheblocks",
no heuristic would catch that, although the human reader did,
immediately).  That would work locally, within a module.  Add
heuristic typechecks inside a file and interface declarations for
cross-file checks, and a lot could be done.

But I think you're excluding exactly the wrong things.   The reason
weakly typed languages like Python are _theoretically_ attractive (as
opposed to effort-minimizing for "lazy" programmers) is precisely that
they allow evals, data-driven, and event-driven programming without
creating huge superstructures of classes and explict down-casting.
Rather than work yourself to death trying to cover more odd corners in
the static check, finding heuristics to help with those dynamics
checks would be more useful.

And maybe a scripting language with strict rules about interface
declarations and loose ones within modules or packages would be the
way to go.

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."