Re: stackless implementation (was Re: New stacklessproposal)

Mark Hahn wrote:

...

> Sorry, my brain goes faster than my typing.

Same problem here. You noticed all the missing chrctrs, lately?

> Yes, I am thinking of tasklets that are prepared for C extensions if
> they happen, but run as pure interpreter tasklets until then.  There may
> be some overhead to mark the stack and copy the stack stub, but that
> doesn't require much memory or speed, right?  It only happens once on
> tasklet creation.

Even less. Initially, all threadlets share the initial stub.
When they create a recursion, this is recognized by counting
the nesting, and a real stack slice copy is created as a new
object, exactly in the moment when they switch to something else.
And they can turn into innocence again, after they left the recursion.

What takes a little time is creating the initial stub at all,
since this is an otherwise unnecessary step. I think I can avoid
this in a future version. But I have to go a connected, compatible
path, and it might take some months to get there.
The problem is that you just can implement what you can think of.
I have understood the better way in principle, but I can't think
it. When I can, then I can implement it, and vice versa.

> I am excited about this.  I would never have dared take on something so
> flexible and powerful if I didn't have you.  I will make sure you get
> full credit.

I hope your users will give *you* the credit. And I hope it will
not be a drawback. From first impressions of your voting, Stackless
seems to be a minor issue, if not even a show-stopper. Make sure
to get a broad user base for the language, because it is better.
This is an easy thing to teach.

Stackless stuff isn't easy to teach, because the student's brains
are spoiled with all the complex structures, which were invented
to overcome the limitations of a stack. They made it a principle,
a religion. I know it is so wrong, but I'm still spending my day
to fight the stack, because it is wired into the language I have
to use. We made some big mistakes in the eighties, welding
stack behavior into the hardware and stackful thinking into our
students. They never learn how limited this concept is. They think
it is natural to have special patterns to achieve a simple task.
They even need a (btw. very good) book about patterns.

Stackful thinking has benefits, for sure, if you need it, it is
just great. If the assumption holds that the world is simple
and single-threaded, and its problems can be solved by a simple,
recursive visitor pattern, this is fine. But it is a big lie.
And to justify this lie, people invented threads, which are
multiple, parallel worlds, no longer controllable, highly complex,
hard to tame, and they thow you into the water, from the healthy,
stackful, blocking world into an insane, parallel, impredictable
world, which of course can solve all problems in a way, but at
a tremendous extra cost, and a huge extra-investment of logic
and math, which most students don't have, and I also say it
should not be required for writing good, parallel programs.

Where I want to go is CSP, C. A. Hoare.
---------------------------------------
(But I'm not talking about this now. later...)

Anyway, my language has to do its best to mediate between
simplicity and power. And I love to have really unlimited, simple
recursion on the application level. Therefore, I'm trying my best to
make interpreted languages behave as "natural" as possible.
While recursion on the interperter level is no problem (unless
you are Guido who even doesn't recognize what problem he is creating), 
we are taking all the problems into the implementation language, for them.

The bad thing is that this implementation language suffers from
the same paradigm, and that really hurts. I have to adopt crazy
schemes (compare some earlier messages) just to make the best use
of the inherent stack optimizations. And the processor is forced
to do this. It would certainly not if it were asked, poor CPU.

Oh well, sorry about this lengthy excursion.
I just wanted to say: If you think you want to have light-weight
threading, then this is a nice thing which can give new insights
to your users. It will probably not happen immediately, and it
will not be a primary selling point. Getting stackless ideas
through the brains and into the industry, and teaching them that
there is much more possible than to switch from a simple program
to an overly complex (threaded) one, will probably take us
another decade.

But it makes sense, and you have my full support, after I failed
so badly with Python, by now.

all the best -- chris

-- 
Christian Tismer             :^)   <mailto:[email protected]>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/