Especially for non-time-critical applications I think using (compiled)
python in place of C++ is a shining possibility. A certain wife of mine
(who asked to be anonymous) is using C++ for a hybrid MIS/Hardware Support
application of great complexity, and the additionaly complexity added
by C++ doesn't help much. For this type of application, Python could
have most of the advantages, with fewer of the gotchas (except that I
think C++ would always be a bit faster -- speed and real-time
considerations are, I believe, the main reasons for some of C++'s more
questionable features).
>What are the obstacles to writing a Python compiler? As far as I can tell,
>the big one is the "eval" statement, which basically forces you to include
>a copy of the compiler in every executable....
You'd only have to include it if eval were used. I think the main
obstacle is that someone who knows what they're doing (this excludes
me, probably) has to write it.
There are lots of nice things that would make a compiled python
faster, like type inferencing. EG: if you write
a = b + c
this must in general be translated to a complicated sequence of
allocations, increfs, decrefs and function calls, which is a shame if
'b' and 'c' happen to be simple longs. Partial type inferencing for
compilation might optimization of such expressions, even if it were very weak
at compile time. Type annotation functions might help, eg:
b = TheInt( f(...) )
c = TheInt( g(...) )
a = b + c
[Idea stolen from Common Lisp]
here the runtime interpretation for TheInt would be a function which
returns its arg if the arg is an int, otherwise raises a
ValueError. The compiler could presumedly use these annotations to
determine that if b+c was ever executed, it should be simple long
addition, perhaps stored to a local variable without heap allocation.
Back to work.... -a.
===
If current trends continue the entire surface of the USA
will be covered by racketball courts by the year 2040.
Something should be done! (Does Al Gore know about this?)
-paraphrased from somewhere.