How to know where a BlockClosure finish

>
> On 25.08.2006, at 17:14, Mathieu wrote:
>
>> Hi,
>>
>> I want to execute several block:
>>
>> block1 value
>> block2 value
>> block3 value
>>
>> but if one block return from a retrun statement I want to quit.
>>
>> [^3] <- want to quit here
>> [3 + 4]
>>
>> So is there a way to know when a block evaluation finish by a return?
>>
>
> There is #hasMethodReturn in BlockContext:
>
> [^3] hasMethodReturn --> true
> [3] hasMethodReturn --> false.
>
> But this does a static analysis of the code... even if the ^is not executed
> (e.g.)
> [nil ifNotNil: [^3]]  hasMethodReturn --> true
>
> so... it would be harder to analyze that dynamically... e.g. (without
> me  thinking
> to much) you could add code (e.g. using ByteSurgeon)
> in front of the return inside a block to set a flag... but I have to
> admit that this
> woud be quite strange stuff...
>
>> I need this to interprete a file containing smalltalk and I want to
>> control the execution beceause I need to add some condition befor
>> evaluate a block.
>
> Why do you need that? I am sure we can find a simple solution if we
> understand
> the problem better.
>
>    Marcus
>
>

> From: Mathieu
> Sent: Friday, August 25, 2006 1:10 PM
>
> Marcus Denker a écrit :
> >
> > On 25.08.2006, at 17:14, Mathieu wrote:
> >
> >> Hi,
> >>
> >> I want to execute several block:
> >>
> >> block1 value
> >> block2 value
> >> block3 value
> >>
> >> but if one block return from a retrun statement I want to quit.
> >>
> >> [^3] <- want to quit here
> >> [3 + 4]
> >>
> >> So is there a way to know when a block evaluation finish by a return?
> >>
> >
> > There is #hasMethodReturn in BlockContext:
> >
> > [^3] hasMethodReturn --> true
> > [3] hasMethodReturn --> false.
> >
> > But this does a static analysis of the code... even if the ^is not
> executed
> > (e.g.)
> > [nil ifNotNil: [^3]]  hasMethodReturn --> true
> >
> > so... it would be harder to analyze that dynamically... e.g. (without
> > me  thinking
> > to much) you could add code (e.g. using ByteSurgeon)
> > in front of the return inside a block to set a flag... but I have to
> > admit that this
> > woud be quite strange stuff...
> >
> >> I need this to interprete a file containing smalltalk and I want to
> >> control the execution beceause I need to add some condition befor
> >> evaluate a block.
> >
> > Why do you need that? I am sure we can find a simple solution if we
> > understand
> > the problem better.
> >
> >    Marcus
> >
> >
>
> Yes you are right
>
> In the script I have 2 kind of things:
> [
> some Smalltalk
> ]
>
> And:
>
> Class selector
> [
> some smalltalk
> ]
>
> So my idea was to call Compiler>>#evaluate:in:to:notifying:ifFail:logged:
> on the string inside the [] for the first things.
>
> And for the second I don't know yet but I don't think it's a probleme.
>
> So I evaluate the "block" one by one. I don't think I can put them all
> together beceause we can declare new method and use it in the next
> "block".
>
> But may be I shouln't evaluate right now juste store them in a
> CompiledMethod...
>
> Math
>
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners

> Hi Math,
>
> How about just adding a parameter?
>
> Blocks are really cool in that they can import context if needed.  This is a
> really amazing feature of blocks for me since the imported context is the
> context when the block was created!
>
> So to solve your problem you could just do the following.
>
> continue := true.
>
> block1 := [someCode.
> someCondition ifTrue: [continue := false. ^someValue]].
> block2 := [someCode].
>
> Then:
>
> block1 value.
> continue ifTrue: [
>     block2 value
> ].
>
> Hope that helps!
>
> Happy coding.

>
> Ron Teitelbaum
> President / Principal Software Engineer
> US Medical Record Specialists
> [hidden email]
>
>> From: Mathieu
>> Sent: Friday, August 25, 2006 1:10 PM
>>
>> Marcus Denker a écrit :
>>> On 25.08.2006, at 17:14, Mathieu wrote:
>>>
>>>> Hi,
>>>>
>>>> I want to execute several block:
>>>>
>>>> block1 value
>>>> block2 value
>>>> block3 value
>>>>
>>>> but if one block return from a retrun statement I want to quit.
>>>>
>>>> [^3] <- want to quit here
>>>> [3 + 4]
>>>>
>>>> So is there a way to know when a block evaluation finish by a return?
>>>>
>>> There is #hasMethodReturn in BlockContext:
>>>
>>> [^3] hasMethodReturn --> true
>>> [3] hasMethodReturn --> false.
>>>
>>> But this does a static analysis of the code... even if the ^is not
>> executed
>>> (e.g.)
>>> [nil ifNotNil: [^3]]  hasMethodReturn --> true
>>>
>>> so... it would be harder to analyze that dynamically... e.g. (without
>>> me  thinking
>>> to much) you could add code (e.g. using ByteSurgeon)
>>> in front of the return inside a block to set a flag... but I have to
>>> admit that this
>>> woud be quite strange stuff...
>>>
>>>> I need this to interprete a file containing smalltalk and I want to
>>>> control the execution beceause I need to add some condition befor
>>>> evaluate a block.
>>> Why do you need that? I am sure we can find a simple solution if we
>>> understand
>>> the problem better.
>>>
>>>    Marcus
>>>
>>>
>> Yes you are right
>>
>> In the script I have 2 kind of things:
>> [
>> some Smalltalk
>> ]
>>
>> And:
>>
>> Class selector
>> [
>> some smalltalk
>> ]
>>
>> So my idea was to call Compiler>>#evaluate:in:to:notifying:ifFail:logged:
>> on the string inside the [] for the first things.
>>
>> And for the second I don't know yet but I don't think it's a probleme.
>>
>> So I evaluate the "block" one by one. I don't think I can put them all
>> together beceause we can declare new method and use it in the next
>> "block".
>>
>> But may be I shouln't evaluate right now juste store them in a
>> CompiledMethod...
>>
>> Math
>>

> -----Original Message-----
> From: [hidden email] [mailto:beginners-
> [hidden email]] On Behalf Of Mathieu
> Sent: Friday, August 25, 2006 8:06 PM
> To: A friendly place to get answers to even the most basic questions
> aboutSqueak.
> Subject: Re: [Newbies] How to know where a BlockClosure finish
>
> Ron Teitelbaum a écrit :
> > Hi Math,
> >
> > How about just adding a parameter?
> >
> > Blocks are really cool in that they can import context if needed.  This
> is a
> > really amazing feature of blocks for me since the imported context is
> the
> > context when the block was created!
> >
> > So to solve your problem you could just do the following.
> >
> > continue := true.
> >
> > block1 := [someCode.
> > someCondition ifTrue: [continue := false. ^someValue]].
> > block2 := [someCode].
> >
> > Then:
> >
> > block1 value.
> > continue ifTrue: [
> >     block2 value
> > ].
> >
> > Hope that helps!
> >
> > Happy coding.
>
> Thanks Ron but in fact it's in a context that we don't know where are
> the return and we also don't know how many "block" we have. :)
>
>
> >
> > Ron Teitelbaum
> > President / Principal Software Engineer
> > US Medical Record Specialists
> > [hidden email]
> >
> >> From: Mathieu
> >> Sent: Friday, August 25, 2006 1:10 PM
> >>
> >> Marcus Denker a écrit :
> >>> On 25.08.2006, at 17:14, Mathieu wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I want to execute several block:
> >>>>
> >>>> block1 value
> >>>> block2 value
> >>>> block3 value
> >>>>
> >>>> but if one block return from a retrun statement I want to quit.
> >>>>
> >>>> [^3] <- want to quit here
> >>>> [3 + 4]
> >>>>
> >>>> So is there a way to know when a block evaluation finish by a return?
> >>>>
> >>> There is #hasMethodReturn in BlockContext:
> >>>
> >>> [^3] hasMethodReturn --> true
> >>> [3] hasMethodReturn --> false.
> >>>
> >>> But this does a static analysis of the code... even if the ^is not
> >> executed
> >>> (e.g.)
> >>> [nil ifNotNil: [^3]]  hasMethodReturn --> true
> >>>
> >>> so... it would be harder to analyze that dynamically... e.g. (without
> >>> me  thinking
> >>> to much) you could add code (e.g. using ByteSurgeon)
> >>> in front of the return inside a block to set a flag... but I have to
> >>> admit that this
> >>> woud be quite strange stuff...
> >>>
> >>>> I need this to interprete a file containing smalltalk and I want to
> >>>> control the execution beceause I need to add some condition befor
> >>>> evaluate a block.
> >>> Why do you need that? I am sure we can find a simple solution if we
> >>> understand
> >>> the problem better.
> >>>
> >>>    Marcus
> >>>
> >>>
> >> Yes you are right
> >>
> >> In the script I have 2 kind of things:
> >> [
> >> some Smalltalk
> >> ]
> >>
> >> And:
> >>
> >> Class selector
> >> [
> >> some smalltalk
> >> ]
> >>
> >> So my idea was to call
> Compiler>>#evaluate:in:to:notifying:ifFail:logged:
> >> on the string inside the [] for the first things.
> >>
> >> And for the second I don't know yet but I don't think it's a probleme.
> >>
> >> So I evaluate the "block" one by one. I don't think I can put them all
> >> together beceause we can declare new method and use it in the next
> >> "block".
> >>
> >> But may be I shouln't evaluate right now juste store them in a
> >> CompiledMethod...
> >>
> >> Math
> >>
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners

>

>>
>> Yes you are right
>>
>> In the script I have 2 kind of things:
>> [
>> some Smalltalk
>> ]
>>
>> And:
>>
>> Class selector
>> [
>> some smalltalk
>> ]
>>
>> So my idea was to call Compiler>>#evaluate:in:to:notifying:ifFail:logged:
>> on the string inside the [] for the first things.
>>
>
> Hi Mathieu,
>
> I would go for a "complete" compiler for this... so let's explain a bit.
> (Hmm,
> Compilers, Parsers, Code Generation. Perfect Newby topics :-)
>
> So: If we look at the new compiler in Squeak, it works on single
> methods. For
> each method, it does
>     - Scann / Parse to build up a Tree of objects that describe the code
>       The root of the tree is RBProgramNode. (other node are e.g.
> RBSendNode,
>       RBVariableNode... things like that).
>     - Analyze the names of variables. The AST only known that "a" is a
> name... but it
>       does not know what it means.. so is this a definition of a temp? Or
>       a use of an existing temp? Or an iVar?. This analysis is done in the
>       class ASTChecker
>     - Code Generation. The analyzed AST is visited by the ASTTranslator
>       to build a CompiledMethod obiect (using IRBuilder). This then is
> installed
>           in a class.
>
> Ok. So for your Scripting system I would do the same:
>
> 1) Scann/Parse the input, build up a Tree
> 2) Analyse the tree (name analysis)
> 3) generate all the needed elements (methods, classes)
> 4) run.
>
> 1) Scann/Parse.
>
> Just re-use the existing Parser, extend the grammar to not parse one
> method, but a whole Script. The root-node of the AST would then be
> some "SqueakScriptNode". This has nodes for all classes that the
> script defined, and nodes for all methods (these will be normal
> RBMethodNodes).
> Then it has the code of the script that starts the whole thing as a special
> method (named #run).
>
> Keep in mind that this Tree-Representation of the Script has not yet added
> any methods or classes to the system.
>
> 2) Analyse. The RBMethodNodes needs to have the ASTChecker run so
>      all variables are bound correctly.
>     This pass could do other analysis things, if needed (don't know any)
>
> 3) Generation.
> Now we need to go through the Tree and generate the smalltalk things
> described in it. E.g. classes that are defined need to be created, we need
> to generate code from the RBMethodNodes and install the resulting
> CompiledMethod objects in the methodDict of the class that they are
> defined for.

>
> The code at the end of the script that is just run will be made a
> CompiledMethod,
> too. For the Script itself, at the beginnig it would be just a method
> that does
> not get installaled but just run.
> Later it might be interesting to have a "SqueakScript" object that is
> kind of like
> a Class but has no name... it could contain helper methods for parsing e.g.
> the command line, stuff like that. This could be implemented as a subclass
> of Behavior. The run method then would be installed in am instance of that.
>
> Hmm... Now I fear we are completely out of the Beginners' realm ;-)
>
> Please ask if you need more explanations... I'm sure this was a  much
> too short
> explanation.
>
>    Marcus
>

>>
>> Yes you are right
>>
>> In the script I have 2 kind of things:
>> [
>> some Smalltalk
>> ]
>>
>> And:
>>
>> Class selector
>> [
>> some smalltalk
>> ]
>>
>> So my idea was to call Compiler>>#evaluate:in:to:notifying:ifFail:logged:
>> on the string inside the [] for the first things.
>>
>
> Hi Mathieu,
>
> I would go for a "complete" compiler for this... so let's explain a bit.
> (Hmm,
> Compilers, Parsers, Code Generation. Perfect Newby topics :-)
>
> So: If we look at the new compiler in Squeak, it works on single
> methods. For
> each method, it does
>     - Scann / Parse to build up a Tree of objects that describe the code
>       The root of the tree is RBProgramNode. (other node are e.g.
> RBSendNode,
>       RBVariableNode... things like that).
>     - Analyze the names of variables. The AST only known that "a" is a
> name... but it
>       does not know what it means.. so is this a definition of a temp? Or
>       a use of an existing temp? Or an iVar?. This analysis is done in the
>       class ASTChecker
>     - Code Generation. The analyzed AST is visited by the ASTTranslator
>       to build a CompiledMethod obiect (using IRBuilder). This then is
> installed
>           in a class.
>
> Ok. So for your Scripting system I would do the same:
>
> 1) Scann/Parse the input, build up a Tree
> 2) Analyse the tree (name analysis)
> 3) generate all the needed elements (methods, classes)
> 4) run.
>
> 1) Scann/Parse.
>
> Just re-use the existing Parser, extend the grammar to not parse one
> method, but a whole Script. The root-node of the AST would then be
> some "SqueakScriptNode". This has nodes for all classes that the
> script defined, and nodes for all methods (these will be normal
> RBMethodNodes).
> Then it has the code of the script that starts the whole thing as a special
> method (named #run).
>
> Keep in mind that this Tree-Representation of the Script has not yet added
> any methods or classes to the system.
>
> 2) Analyse. The RBMethodNodes needs to have the ASTChecker run so
>      all variables are bound correctly.
>     This pass could do other analysis things, if needed (don't know any)
>