What If..... Strong Types
Don Garrett
garrett at bgb.cc
Tue Jun 18 19:57:40 EDT 2002
Don Garrett wrote:
> I'm not suggesting any real changes to any, only proposing a thought
> experiment.
>
> What if Python had been built from the start with strong types? And I
> mean strong types, not strong typing. The distinction I am trying to
> draw is that variables would not be typed, but that all types would have
> rigid interfaces.
I seem to have drawn a lot of responses that say "Don't mess with Python".
That tells me that I didn't do a very good job of posing the question. To be
clear, I have no intention of writing any code or changing anything. I don't
even think that standard Python would benefit from the changes I'm suggesting.
I'm just tyring to understand what would or would not be a good idea in a
language design and (more importantly) why.
One thing I was NOT suggesting was type tagging. Part of what led to my
post was the realization that most verbosity in strongly/statically typed
languages is the redundancy of type tagging, and that strong interfaces can be
had without it.
Here are the two reasons that lead me to think that a Pythonish language
with strong interface definitions would be a good idea (at least in theory).
One:
I THINK (am not sure) that this is the smallest (major) change
that could be made to the language spec which would produce a language which
was easily compilable.
This is important because, good as python is, there are jobs for which it's
unsuitable. For example, it can't be used to write an operating system kernel
or device driver. Python modules are often (re)written in C/C++ when
performance is critical. It would be nice if something more Pythonish could be
used instead.
My biggest doubt here is.... could highly efficient compilation be done
without continual type tagging? Obviously, careful data flow analysis would be
needed.
I'm totally ignoring other properties that such a compiled language would
need to be really useful. An example being that it would need to be able to
link directly against C/C++ libraries.
Two:
I've had a long term idea about building a really, really smart IDE.
Something that provided high-level programming support on several levels, as
well as detailed analysis of the code. I know this isn't original.
For example: a programmer should be able to ask which exceptions an method
could raise and which runtime conditions would cause those exceptions to be
raised.
That kind of analysis is not easy to do, and will often break into results
that are to vague to be useful. It's easier to build such a system with a lot
of facts that are "for sure" not "probably, unless somebody did something
wierd". As a note: I think such a system is almost impossible with general C++
because it simply has too many ways to "do something wierd".
Python tends do things by convention, not by enforced rules. This is a good
thing for programmers. But it's hard for software to deal with if the software
is going to do more than just run it.
--
Don Garrett http://www.bgb.cc/garrett/
BGB Consulting garrett at bgb.cc
More information about the Python-list
mailing list