Why this closure is not #isSimple ???

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Why this closure is not #isSimple ???

GLASS mailing list
Hi,

'[ :co | 
  | d |
  co collect: [  d := 0 ]  ]
' evaluate isSimple 

Answers false and #_cost answers 2 (complex).
It seems related to the assignment of a temp var (defined inside the closure... 'd' in my example)  from inside another closure ( [d := 0] in my example)

Any idea why? Of course that is a dummy closure that I reduced from my original one in order to the have the smaller reproducible closure to illustrate my problem. 

Thanks in advance, 

--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Why this closure is not #isSimple ???

GLASS mailing list
On 11/06/2015 11:10 AM, Mariano Martinez Peck via Glass wrote:

> Hi,
>
> '[ :co |
>   | d |
>   co collect: [  d := 0 ]  ]
> ' evaluate isSimple
>
> Answers false and #_cost answers 2 (complex).
> It seems related to the assignment of a temp var (defined inside the
> closure... 'd' in my example)  from inside another closure ( [d := 0] in
> my example)
>
> Any idea why? Of course that is a dummy closure that I reduced from my
> original one in order to the have the smaller reproducible closure to
> illustrate my problem.
>
> Thanks in advance,

In 3.2.x, the outer block is not simple because the inner block is not
simple. The inner block is not simple because it accesses a variable
outside of its own scope.

I understand that the outer block's result is somewhat surprising.

In 3.3, the inner block will still not be simple, but the outer block
will be simple independently of whether or not it contains a non-simple
block.

This should be less surprising.

Regards,

-Martin
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Why this closure is not #isSimple ???

GLASS mailing list


On Fri, Nov 6, 2015 at 4:51 PM, Martin McClure <[hidden email]> wrote:
On 11/06/2015 11:10 AM, Mariano Martinez Peck via Glass wrote:
> Hi,
>
> '[ :co |
>   | d |
>   co collect: [  d := 0 ]  ]
> ' evaluate isSimple
>
> Answers false and #_cost answers 2 (complex).
> It seems related to the assignment of a temp var (defined inside the
> closure... 'd' in my example)  from inside another closure ( [d := 0] in
> my example)
>
> Any idea why? Of course that is a dummy closure that I reduced from my
> original one in order to the have the smaller reproducible closure to
> illustrate my problem.
>
> Thanks in advance,

In 3.2.x, the outer block is not simple because the inner block is not
simple. The inner block is not simple because it accesses a variable
outside of its own scope.


Sure, but I am sending the message to the outer block, not the inner block. 
 
I understand that the outer block's result is somewhat surprising.


Yes, I think it should be considered a bug because THAT closure (the one I am sending the message) IS SIMPLE. Right? 
 
In 3.3, the inner block will still not be simple, but the outer block
will be simple independently of whether or not it contains a non-simple
block.

This should be less surprising.


Yes, this is the correct behavior I would expect. 
Do you know if there is a workaround for 3.2.x ? 
 
Thanks Martin for the explanation. 


--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Why this closure is not #isSimple ???

GLASS mailing list
On 11/06/2015 12:01 PM, Mariano Martinez Peck wrote:

>
>
> On Fri, Nov 6, 2015 at 4:51 PM, Martin McClure
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 11/06/2015 11:10 AM, Mariano Martinez Peck via Glass wrote:
>     > Hi,
>     >
>     > '[ :co |
>     >   | d |
>     >   co collect: [  d := 0 ]  ]
>     > ' evaluate isSimple
>     >
>     > Answers false and #_cost answers 2 (complex).
>     > It seems related to the assignment of a temp var (defined inside the
>     > closure... 'd' in my example)  from inside another closure ( [d := 0] in
>     > my example)
>     >
>     > Any idea why? Of course that is a dummy closure that I reduced from my
>     > original one in order to the have the smaller reproducible closure to
>     > illustrate my problem.
>     >
>     > Thanks in advance,
>
>     In 3.2.x, the outer block is not simple because the inner block is not
>     simple. The inner block is not simple because it accesses a variable
>     outside of its own scope.
>
>
> Sure, but I am sending the message to the outer block, not the inner block.
>  
>
>     I understand that the outer block's result is somewhat surprising.
>
>
> Yes, I think it should be considered a bug because THAT closure (the one
> I am sending the message) IS SIMPLE. Right?

I don't recall the exact details, but I think that the way blocks in
3.2.x are handled internally, the outer block is actually not simple (in
the way it's handled internally). Blocks are handled differently in 3.3,
so the outer block can be simple, as you'd expect.

Regards,

-Martin

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Why this closure is not #isSimple ???

GLASS mailing list
I can confirm this is fixed in 3.3.

Cheers,

On Fri, Nov 6, 2015 at 5:04 PM, Martin McClure <[hidden email]> wrote:
On 11/06/2015 12:01 PM, Mariano Martinez Peck wrote:
>
>
> On Fri, Nov 6, 2015 at 4:51 PM, Martin McClure
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 11/06/2015 11:10 AM, Mariano Martinez Peck via Glass wrote:
>     > Hi,
>     >
>     > '[ :co |
>     >   | d |
>     >   co collect: [  d := 0 ]  ]
>     > ' evaluate isSimple
>     >
>     > Answers false and #_cost answers 2 (complex).
>     > It seems related to the assignment of a temp var (defined inside the
>     > closure... 'd' in my example)  from inside another closure ( [d := 0] in
>     > my example)
>     >
>     > Any idea why? Of course that is a dummy closure that I reduced from my
>     > original one in order to the have the smaller reproducible closure to
>     > illustrate my problem.
>     >
>     > Thanks in advance,
>
>     In 3.2.x, the outer block is not simple because the inner block is not
>     simple. The inner block is not simple because it accesses a variable
>     outside of its own scope.
>
>
> Sure, but I am sending the message to the outer block, not the inner block.
>
>
>     I understand that the outer block's result is somewhat surprising.
>
>
> Yes, I think it should be considered a bug because THAT closure (the one
> I am sending the message) IS SIMPLE. Right?

I don't recall the exact details, but I think that the way blocks in
3.2.x are handled internally, the outer block is actually not simple (in
the way it's handled internally). Blocks are handled differently in 3.3,
so the outer block can be simple, as you'd expect.

Regards,

-Martin




--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass