needs to ship with a compiler!
There, I've said it. But what
are my reasons?
I truly believe that your
programming language influences the way you go about solving a problem,
and their is a mindset to programming in a dynamic language like
Python/Perl/TCL/AWK/... that can lead to different types solutions (and
even perceived problems), than programmers in say
Java/C/C++/C#. (OK some of the differences are also down to other
factors such as IDE's and OS which also affect how you solve an issue).
Lately
I have seen
posts commenting on the 4.0 release of C# will be
adding dynamic type resolution capabilities via a keyword that will
allow C# to finally do Duck Typing. The
done this trick from its outset. Thinking about it though, I don't
think it will make C# programmers style change to mimic that of
dynamic language programmers as they would have to stick their keyword
on every definition and leave behind their perceived safety of run-time
type checking. They will, I think,rather use it as another resource
that they can dip into, forming rules/design patterns on where it fits
best and use it from overwhelmingly statically typed source code.
When
I look critically at Python, (yep - I do do that from time to time),
Python 3.0 has optional type decorations - but no compiler,
and Python distributions such as Enthoughts, include external modules
to help in creating compiled code to link to Python,, but we need to
have a complete solution out of the box i.e. CPython should be shipped
with a defined method of compiling 'Python-like' source code into
machine code as part of its standard library and enshrined in the
reference guide. That would allow Python programmers to do the opposite
of what the C# programmers can do: write a mainly dynamic program -
with dynamic language idioms, but be able to seamlessly have part of
their recognisable Python code compiled . Maybe all it would take is
the addition of a new static
keyword to apply to classes/functions/modules.
You
would need to think of static/dynamic as a continuum where instead of
having languages bunched at either end, you would have a smearing out
towards the middle.
Existing languages have too much
static vs dynamic baggage, but maybe a new language with type
inferencing and where you were forced to first define the default type
checking regime as either dynamic or static, then be given the option
of declaring particular 'things' as being at either run-time or
compile-time would lead to a language that might breed new
programmers with more interesting ways to solve problems.
-
Paddy.
Why would you need a static keyword? Common Lisp can compile to machine code even with all it's dynamic code. Of course you need to distribute the Common Lisp image with the whole of CL to ensure that it still works after all the macro expansions and potential runtime definitions.
ReplyDeleteCPython has always shipped with a compiler. It always compiles into object code and then executes the object code. Of course the compile only happens when a source file has changed.
ReplyDeleteIf you mean that it needs to ship with a bundler that creates .EXE files, then write a PEP explaining which of these tools should be annointed as the one true way.
Here is a 5 year-old article explaining some of this: http://effbot.org/zone/python-compile.htm
Cython (http://cython.org/) is getting pretty close in this direction. Some things still aren't implemented yet such as closures and generators, but work is being done on that front.
ReplyDeleteSage (http://sagemath.org/) uses it extensively (75,000+ lines) to make the low level code run at near C speed and to interface with existing C and C++ libraries.
Hi TechnicalBard,
ReplyDeleteYou would need some sort of static keyword because in Python, you are allowed to dynamically load a module not present at compile time or other wise execute code not available at compile time that could, for example, monkeypatch any class. a static keyword would allow it to overcome any decision to therefore typecheck all classes at runtime.
I am presuming that you couldn't gain much by static compiling *and* runtime checking for attempts to monkeypatch.
- Paddy.
Hi Anonymous,
ReplyDeleteI do mention to machine code in the article, but mean to anything that will give you that compiled C level execution performance which current CPythons bytecodes don't achieve.
Hi Mike, thanks for your info on Cython.
- Paddy.
the dynamic keyword in C# does not mean that C# suddenly has dynamic typing semantics on demand. it means that the compiler has two things: 1. a form of type inference. and 2. a way to perform or create polymorphic operations based upon how an object is used (could be called: operational type inference).
ReplyDeleteupon compilation of a dynamic variable, the compiler will inspect how the variable is used (what messages are sent to it) and then it will most likely generate a list of all the possible matches for classes that can perform these operations. It will then either know the type of the object, or it will generate a runtime type check that will perform the correct operation based on the type of the variable at that time.
in no way does this make the compilation process any less static, and in no way does it make the runtime more dynamic. It generates some code so the developer does not have to.
also, adding static semantics to python probably won't achieve what you think it will. what you are probably looking for is a way to get better performance. However there are other projects that are working on optimisations for dynamic languages. Specifically javascript interpreters such as TraceMonkey, V8 and SquirrelFish Extreme. All the optimisation techniques introduced by these technologies (most of which were inspired by research from SmallTalk and Self) can be applied to other dynamic languages such as python to get improved performance.
I think the important thing is that the runtime MUST be able to handle all Python code, including code using the wackiest dynamic introspection and prodding you can think of. It doesn't have to be fast (although it shouldn't be slower than it is today), but it does have to run correctly.
ReplyDeleteThere have been some attempts to statically analyze Python code and convert them to C++, like Shedskin, and the key problem is that they don't let you write dynamic code. That prevents them from becoming a standard solution.
As Bark Madly above mentioned, there's actually a lot that can be done to make Python faster without introducing new keywords, by having a smart just-in-time compiler. Javascript is even more dynamic than Python in many ways, and it's seen drastic speedups with primitive first-generation JIT compilers, all with no changes to the language (especially since it's standardized.)
Granted, Psyco already does several of the things that V8 and Tracemonkey are trying to achieve, but there's probably still some lessons to be learned from them.
i have long be wishing that python would ship with a standard c compiler installation. i'd be fine if there were restrictions on what code that compiler can compile, but if i had to write actual c code, that wouldn't be so hot. there are a couple of projects out there that manage to translate some kind of restricted python source code to c and compile it. it just has to be packaged so people on all three major OSes can simply click to install. in essence, c must become more accessible so it can be used by the masses. one major roadblock on windows is standard python's dependence on visual c which seemingly (but not with ctypes? i dont know) extends to the compilation of extensions as well, sort of a bad joke really.
ReplyDeleteHi ey,
ReplyDeleteI wouldn't want the rigid restriction that any static compilation ability handle all Python code - it's just not gonna happen. I would rather we explore what is achievable with the goals of making it easier to write faster executing code, and being able to more easily link to compiled libraries.
- Paddy.
Hi love encounter flow,
ReplyDeleteOn the use of non-free compilers: If Python progressed to being shipped with a compiler, then a free compiler for platforms could be provided, with the option of either people compiling Python with a non-free compiler themselves, or buying a version pre-compiled with whatever C compiler they need, from a third party such as Enthought?
- Paddy.