Re: Python discussion, anybody?

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

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

    Todd>   Ok, so where do you put this?

Whoa, whoa, wait a second!  You obviously have a different concept of
"this" than I do.  We were talking about syntax errors, you mentioned
a tool which would check whether a given attribute was defined or
not.  I assumed a static, local check.  LISP does that on byte
compilation, as does Python (although Python's is a weaker set of
checks in some ways in that it doesn't issue as many warnings).

    Todd>   Really? Are you sure--it'd be an operation which would
    Todd> depend on having all the modules of a program at once (and
    Todd> is somewhat particular to that program)--any little change
    Todd> to one class could have all kinds of repercussions.

I see; you're talking about program verification; this is undecidable,
to start with.  Shall I go on to mention the human factors
difficulties?  :-)

    Todd>  E.g., if I pull an object off a list and call some method
    Todd> on it, this would require tracing back all the possible
    Todd> objects that could have ended up on that list (in this
    Todd> particular program)

Um, CORBA?  Oops.  You now have to worry about the whole World Wide
Web.  I hope your net connection is up!

    Todd>   Propagating every object creation to every method call
    Todd> that could happen for a large program would be a pretty huge
    Todd> calculation, but it's exactly the advantage you get with
    Todd> strong typing (and indeed, once this is done you could then

No, it's not the same.  Strong typing works by precluding a host of
useful operations.  What you're talking about is far more powerful
than strong typing could be.

    Todd> proceed with a whole slew of optimizations not otherwise
    Todd> possible, I believe).

I doubt you'll get so much optimization.  The point of polymorphism is
that it will be very difficult to predict what object you'll have.  It
is that predictability that strong typing buys you.

LISP engines (and Python and Perl for that matter) are themselves
generally written in strongly typed languages like C, lex, and
yacc[1], precisely because they deal with well-specified grammars and
semantics.  Not to mentioned being executed over and over again,
justifying very sophisticated optimizations, which as you point out
are much more easily implemented with strongly typed languages.

Python and Perl, on the other hand, are typically used for problems
where by the time you realize what the correct specification is,
you've changed employers twice.  ;-)  Large Python or Perl programs
grow out of small ones, usually.  Few people start out to write a
million-line app in Perl.  OTOH, hundreds of thousands do so with Ada
:-P

And LISP?  Well, LISP is for problems whose rough definition won't be
complete before the human race is extinct.

Verifying these things would be pretty useless.  The best you can
hope for (and what LISP and Python provide to some degree) is an
environment where "what I say" usually maps pretty directly to "what I
mean".  Then you verify the small pieces, and use them to build bigger
pieces where DWIS == DWIM.

Applying -O9 to a buggy design is pretty silly.

    Todd>   Lisp does this?

Program verification?  Of course not.


Footnotes: 
[1]  To be precise, relatively strongly-typed app-specific dialects of
the not-very-strongly-typed language, C.

-- 
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."