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

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 Ron@USMedRec.com

...

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

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

Marcus Denker a écrit :

...

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.

5. 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)

In Parser2>>#parse:class:noPattern:notifying:ifFail: I saw:

[tree verifyIn: scope] on: SemanticWarning do: [:ex | ex correctIn: self]

When do SemanticWarning are throw?

In the script context do we need to call #correctIn: Or what #correctIn: serve for?

Thanks Math