I would like to know from SqC guys and other what is missing in BC that 
would
impede its integration into the main image (like a decompiler...)?

I would like to know if the new architecture is a problem for other 
processors.

I think that it would be good to have a list of things that should be 
developped.
I'm really concerned by the fact BC is a big changes and that some people 
may be afraid to change. This would be a pity to have a big change 
discarded just because this is a big change.

Stef



On Tuesday, April 30, 2002, at 09:32  PM, Anthony Hannan wrote:

>
> --- Roger Vossler <rvossler at qwest.net> wrote:
>> I read the material concerning Block Closures (BC) on the GaTech web
>> site, but it's a bit beyond my meager understanding.
>
> Sorry it is just technical, hopefully the answers below will help.  
> Others may
> want to add to my answers.
>
>> I have a couple of questions:
>>
>> 1) Why is BC so important?
>
> BC speeds up the Interpreter and correctly interprets the scopes of 
> blocks.  To
> elaborate on the second point:  Blocks holding their own temps (block 
> closures)
> is more correct from a scoping point of view than method contexts holding 
> the
> temps for its embedded blocks (current Squeak).  For example:
>    #(a b c) do: [:s | [Transcript show: s] fork]
> will print 'abc' in the BC version but 'ccc' in the current Squeak 
> version.
> The BC version is correctly scoped because the block variable s has a 
> different
> binding on each iteration.  However, in the current Squeak version the 
> block
> variable s has only one binding held in the home method context and just
> changes value on each iteration.  By the time the forked blocks are 
> executed s
> is holding the last value.
>
>> 2) What does one gain from this capability?
>
> You gain correctly scoped blocks, which allows you to more easily create 
> truely
> independent functions/blocks.  Sometimes this is preferred over creating
> special small "function" objects or using additional methods just so you 
> have
> another scope to bind temps to.  For examples of sophisticated uses of 
> blocks
> that would not work in the current Squeak implementation unless they were
> rewritten using more methods/classes, see the block closure test cases in 
> the
> BC image or on the BC swiki page in the Convert section.
>
>> 3) Do most other Smalltalk systems have this capability?
>
> Yes.
>
>> 4) Is this capability "nice to have" or is it "really essential"?
>
> It is not essential since code like the example above can be rewritten to 
> use
> an intermediate method to provide the missing scope.  For example, the
> following will work correctly in the current Squeak implementation:
>    UndefinedObject compile: 'forkWriting: s   [Transcript show: s] fork'.
>    #(a b c) do: [:s | self forkWriting: s]
> BC just makes it much easier to make these blocks independently scoped.
>
>> 5) If BC is "really essential", how has Squeak managed to get along
>> without it thus far?
>
> Block closure is not essential as noted above.  But it does force people 
> to
> sometimes write code the long way like the example above.
>
>> I'm not looking for detailed technical information, but rather, an
>> indication of why the Squeak community needs to make this change
>> which apparently has big impacts on image formats, VMs, et al. As
>> someone noted: we don't want to do this more than once.
>
> Two main reasons why Squeak needs BC are:
> 1. Block closures conform to the scoping rules of [...] (BC is more 
> correct).
> 2. This BC implementation is faster.  Since the interpreter had to be 
> changed
> anyway to accomodate block closures I took the opportunity to make further
> changes to speed up the whole interpreting process.
> Either of these may be important enough, but together, I think they (plus
> possibly other VI4 enhancements) makes it worth the pain to switch the
> community to a new image format.
>
> Of course, we can make the switch as painless as possible by providing the
> image converter with the new VM and have the new VM trigger the converter 
> when
> it tries to open an old image.  The major problem is that image conversion
> takes a long time (about an hour on a 3.2 image on my 533MHz Intel).  Also
> trying to open a new image with an old VM will just report a bad format
> message.
>
> Cheers,
> Anthony
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - your guide to health and wellness
> http://health.yahoo.com
>