On 04/11/2007, Rob Withers <reefedjib at yahoo.com> wrote:
>
> ----- Original Message -----
> From: "Igor Stasenko" <siguctua at gmail.com>
> To: "The general-purpose Squeak developers list"
> <squeak-dev at lists.squeakfoundation.org>
> Sent: Saturday, November 03, 2007 4:57 PM
> Subject: Re: Thoughts on a concurrent Squeak VM
>
>
> > On 04/11/2007, Rob Withers <reefedjib at yahoo.com> wrote:
> >>
> >> ----- Original Message -----
> >> From: "Igor Stasenko" <siguctua at gmail.com>
> >>
> >> > I found another thing, which may be interesting:
> >> > http://www.stackless.com/
> >>
> >> Ok, I took a look and I decided I do not like Python.  :)   What a
> >> horrible
> >> syntax.
> >
> > I don't like a python myself, a two weeks of programming on it was
> > enough for the rest of my life ;) But i pointed more on concepts which
> > allowed concurrency in Python VM , and i think we can learn on their
> > experience.
> >
> >> On the topic of microstacks in stackless, I figure we already do
> >> this in Squeak.  Each method has a stack and the msg sending is like the
> >> channel comms.
> >
> > Not exactly. See, the one main difference, i think, that we can't
> > lookup for a method before all arguments are evaluated even for known
> > receiver.
> >
> > I mean that in code:
> >
> > object1 method1: object2 method2
> >
> > we can't do lookup for #method1 before done evaluating a method2,
> > because in method2 there can't be things which can change the class of
> > object.
> > Thus, we need to push args on stack or create an argument-vector  to
> > collect all arguments, and then, only after having all of them, we can
> > actually do lookup and create a context for receiver's method.
>
> Unless you are using futures. :)  In that case the invocation schedules the
> message for later, and we move to sending method1: before method2 is
> evaluated.  Even if method2 changes the class of object1, it just happened
> to late to be of importance.
>
>
> >> >
> >> > If we suppose that we built a chain of future message sends in:
> >> >
> >> > object future message1 message2 message3 ... messageN.
> >> >
> >> > then if an error occurs in message1 (or there is non-local return), it
> >> > means that all chain of futures, which awaits for activation (message2
> >> > ... messageN) should be thrown overboard.
> >>
> >> Actually, the error should propogate through all future msgs, not thrown
> >> overboard.
> >>
> >
> > Err,  why? IIRC, an error(exception) initiates a stack unwinding
> > looking for context which can handle it.
>
> object future message1 throws an error.  message2 will now be sent to this
> error and will itself break with an error, and so on up the line.  It is
> another way of propogating errors.
>
True, but not for non-local returns.

> Rob
>
>
>


-- 
Best regards,
Igor Stasenko AKA sig.