Re: Re: Prothon in Prothon (blue sky :-)

"Mark Hahn" <[email protected]> writes:

> Joe Knapka wrote:
> 
> > You know what would *really* rock?  A practical Prothon compiler in
> > Prothon.  Being self-hosting seems to be a fundamental characteristic
> > of "system" languages vs "scripting" languages (along with low-level
> > bit-twiddling facilities).  If Prothon could compile to a sufficiently
> > efficient form that a fast Prothon compiler could be hosted on the
> > Prothon runtime, we would have a nice high-level system/scripting
> > language. Java is the only other example of such a thing I can think
> > of -- and who the heck wants to use Java?  (I'm not even certain that
> > Java compilers are generally implemented in Java, but I assume at
> > least some are.)
> 
> Compilers for interpreted languages are a bit fake.  The nature of an
> interpreted language requires that some core engine be present for garbage
> collection, and other housekeeping, plus overloaded method calling and other
> operarations are such expensive operations (especially in prototype
> languages) that it is almost always prudent to factor it and other code out
> into common code.  You can call that common code an interperter or something
> else.

That shouldn't stop you from being able to compile most
code all the way down to machine code. There are GC'd languages
that compile to native code, Lisp being a prime example.

What I mean is, when you see

z = a + 3

in a Prothon program, there's no fundamental reason that can't
turn into

  mov ax,[addr_of_data_field_in_a_object]
  add ax,3
  mov [addr_of_data_field_in_z_object],ax

in the running program, as opposed to going through the whole Prothon
method-invocation machinery to call a.__add__(). Even if those objects
are being memory- managed by some other thread, or whatever.

There may be lots of *practical* reasons that kind of compilation
can't be done, but there's no *fundamental* reason.

> An application can be self-hosting by just having a small footprint
> interpreter.  Prothon so far is 240 KB in win32 and that is with all of
> Python's methods.  This is a big feature that comes from simplicity.

Certainly. (Still pretty huge, though, by the standards of, say,
Forth, where a 10K interpreter would be considered bloated :-)

> The real goal of a compiler should be speed.  Recently though, interpreters
> have been faster than C code.

I think that those interpreters are actually JIT compilers, for
the most part. (I could be wrong.)

>  I can't remember the name of it, but there is
> a project in Python that processes your python app and runs it faster than
> an equivalent C code, all in the python interpreter.  People are saying it
> works so well that they will quit using C modules for speed.

There's Psycho, which is essentially a JIT native-code compiler
for Python. And then there's Pyrex, which allows native code
to be written in Python-like syntax (I think Pyrex is Greg's
baby).

> If possible I'd like to build this same speed-up trick into the Prothon
> interpreter for every program it runs.  I'm not going to be working on speed
> until late summer though.

Sure. I was just talking ;-)

-- Joe

-- 
Resist the feed.
--
If you really want to get my attention, send mail to
jknapka .at. kneuro .dot. net.