RE: Prothon on CPython intrepreter? [PROTHON]

Christian Tismer wrote:

> No, you'd better push me to move on to the next version,
> or you would get *really* ugly update problems of a triply-=20
> stacked implementation :-(
>=20
> ...
>=20
> >>>I would give up on the minimum number of ideas to make this
> >>>work.  I would have to give up OS native threads and use your=20
> >>>threads.  I would probably give up on object locking.  The
>  >>> idea is to make the CPython C extensions work with Prothon.
>=20
> This is what can be included under the "whore" thing :-)

I chose my words carefully. :-)
=20
> >>This would immortalize the GIL, since CPython C extensions=20
> expect it.
> >=20
> > For the CPython version of Prothon this is true.
>=20
> Yeeks, he is true! Mark, Nooo, why?

I thought you'd be happy I was using only your tasklets.

> Stick with youself, do what *you* feel is right for you.
> Whatever you do, don't think to acquire the BDFL's sympathy,
> this is impossible, especially if you are so mad to make your
> code base based upon Stackless. <2.75 wink> :-)
>=20
> [how, the heck! ]

Actually I'm not sure Guido likes this idea.  I sent the email 1.5 days =
ago
and he hasn't responded.  Maybe he wants me to do the CProthon so he can
learn from my new interpreter.  He specifically said he thought my =
object
locking was interesting.  Also I don't think he would necessarily like =
my
mucking with his Python.

> > Imagine that the Prothon interpreter is a superset of the CPython
> > interpreter, but the Prothon language is just Prothon.
>=20
> Doing everything completely like the CPython intpr does,
> *and* doing everything what the Prothon intpr does.
> Wouldn't it be *way* simpler to just have two interpreters?
> I proposed this at some time (not being the first one),
> and you vehemently rejected. But this seems to do *much* more?
>=20
> [me old fart grumbling on masochism]

I thought it would be simpler, but I may be wrong.  You know better than =
me.
I don't know the CPython code.

I just got done looking at the IronPython code and Jim made that look
simple.  I made the big conceptual leap that it could be done in CPython
also.  That leap might be too big. :-)

..<snip>..
=20
> You were almost releasing Prothon 1.0.
> Why can't you just let this happen?
> There is a chance to get something halfway
> useful go out, and then you need to revert,
> and increase the problem by a factor of three?

I was working on the 1.0 release before I knew there was a possibility =
of a
solution that would get a library.  I would find it hard to be motivated =
to
go back and work on 1.0 knowing what I know now.  It would be a month to =
get
to alpha and the end of the year to get to a production release then I'd
have no library.

..<snip>..

> If you are really on the path to "the real solution", I hope
> nopt to hinder you. But if you are on the path to shoot
> yourself into the foot, I want to protect you, if I can.
> Unfortunately, I can't determine this.

Luckily I can switch rapidly when I realize I make a mistake (as I often
do).  The investment into the Prothon design made thus far this year is =
not
in danger of being lost.  The worst that can happen is that I will be
embarrassed and I don't embarrass easily.

> > I haven't made the decision to do this yet.  I haven't=20
> announced it.  I'm
> > still waiting for feedback from everyone on the idea.  I'm=20
> taking your
> > feedback as saying "this will be messy" and "I wouldn't do it".
>=20
> I would love to tell you the opposite. I love the way how
> you tackle problems, and how you extrapolate into the next
> level of abstraction. You have reached much more than I was ever
> able to reach.
> Now I would like to see you succeed, and I'm willing to support
> you wherever I can.

Wow!  I am really flattered.  Thanks for the kind words.

> I may be completely wrong: My perception is that by going the
> CPython way, you are gathering all the problems that Prothon
> was able to surround so far, by its novelty, and by its radically
> different aproach. This is the big Prothon promise!
>=20
> By going .NET, you get into some difficulties, your working
> set of tools is changed, partially for the better partially
> for worse. That's ok, so far.
>=20
> By going CPython, you are entering a completely different
> world. This world is optimized for CPython, and only for
> CPython, and all its paradigms are promoted through
> CPython in an almost unchangeable way. This is so hard
> to break, and so impossible to change, that the only way to
> really overcome it is a complete re-implementation from
> scratch.=20

Ouch!  It appears that my optimism may be unfounded.

> This is why I started PyPy, in January 2003.
> I knew that it is impossible, even (or maybe just) for me,
> to get around this in any other way than to have 10 people
> on a radically different approach:

I didn't know you started PyPy.  How did you get 10 people to work on =
it?

> Don't do it in C at all, but write it in the target language.
> If you follow the current path, you are overwhelmed by the
> massive code base, and you are dead-born by definition.
> Reality strikes back, and in such a hard way!
>=20
> I spent 5+ years of my life to keep that crazy Stackless
> project alive, always fighting this accelerating optimization
> and featurism of CPython, which was not there when I started,
> and if I had known before, I would not have started Stackless
> at all! (or maybe I had, because I'm known as mad enough).

You are making .Net sound better all the time. :-)

> The simpler thing that I might propose to you as a friend is
> something like: Try to marry the two, as I said a while before.
> Maybe steal the stackless interpreter, whatever fits you,
> but don't try to solve the big problems. Let CPython have
> the GIL, don't have it, yourself. Make your own interpreter,
> let the other one co-exist. Make your own objects, and find
> a mapping.

I have never liked the dual-interpreter idea as you know.  Trying to =
keep
two interpreters in sync sounds like a real headache.  Now this may be a
better idea than my current one, but if so then my current one really =
sucks
and I need to drop it.

> But defining your own language on top of the monthly-moving
> target of an always-changing code base, which is not to any
> rate compatible with your basic goals, and even worse
> morphing your goals just to get the full python-dev support?
> I guess you can have the latter, even if you are completely
> ignoring CPython.

None of my goals are to get support from Prothon-dev or Guido.  I was =
just
trying to be friendly.

> If you want to do Prothon, do Prothon and f**k the rest.

As long as I can do it with a library and a community.  I have =
discovered in
this whole experience that the community is as important to me as the
technology.  I really enjoyed meeting everyone at the VanPy Python =
workshop
and I want Prothon to have a community like Python.

> If you want to do .NET, be aware of Jim Hugunin and
> IronPython. I would never try to compete with him
> because he has proved as a genious, but you might very
> likely be superior enough. I'd personally retract early.

The more genious he is the more I can steal from him. :-)  Maybe I can =
even
get him to help like I have gotten you, Greg, and Paul to help. :-)

> If you want to do a better CPython, ignore CPython and
> come to PyPy. There you can find a group of people of
> at least your craziness, and you'll have great support.

Will it run all the CPython libraries?  How fast is it?  How close is it =
to
beta?
=20
> Having said all this, I'm offering my help, of course.
> If I can help at all. But please find a path that
> provides your fans (count me in) with a result in 2004.

That's what I want to do.  From what you say, it appears I may be doing =
.Net
first.  In that case I won't be using stackless until next year.  I =
would
hate to lose lightweight threads though.  Running coroutines with heavy
threads is kind of a joke.  If I could figure out how to do lightweight
threads on .Net I'd have the only language with them though.

I will take a more in-depth look at the Cpython code over the next =
couple of
days.  If I see a way to do what I want to do I will ask you for
verification that my ideas will work.  If I can't figure out a way to do =
it
then I will agree that it is a bad idea and move on to other ideas, =
probably
.Net.

Thank you very much for your valuable feedback.