[squeak-dev] Full block closure return value testing/using in workspace?

Lauren P drurowin at gmail.com
Mon Nov 28 17:01:42 UTC 2022


I read somewhere to never write ^ in a block you intend to give out.  I use
it to abandon methods in assertions and never any other time.

One thing I do know from experimentation is it marks the method finished,
so you can't call the block twice.  You'll get BlockCannotReturn nowadays.
It used to be a segmentation fault.

On Mon, Nov 28, 2022, 04:33 LawsonEnglish <LEnglish5 at cox.net> wrote:

> OK, thanks.
>
> I had thought perhaps it would act more like a break and take one to the
> outside of the block, but instead it returns to the caller, as I should
> have realized.
>
> Stilly me.
>
> L
>
>
> > On Nov 28, 2022, at 04:15, Tobias Pape <Das.Linux at gmx.de> wrote:
> >
> > Hi Lawson
> >
> > good to see you.
> >
> >> On 28. Nov 2022, at 11:58, LawsonEnglish <LEnglish5 at cox.net> wrote:
> >>
> >> I was trying to test some ideas and was using the new FullBlockClosure
> to return values for further use in a workspace.
> >>
> >> This works with “print it”:
> >>
> >> [Transcript show: 2;cr. ^2] value => 2
> >>
> >> This does not work:
> >>
> >> test := [Transcript show: 2;cr. ^2] value <do it>
> >>
> >> test => nil.
> >
> > Yes, and that is expected.
> >
> > Two things:
> > First, it seems you want to assign the _return value_ of a block to a
> variable.
> > To achieve this, do
> >       test := [Transcript show: 2;cr. 2] value "Note the missing
> caret/return"
> >
> > This is because the last statement of a block will be its return value.
> >
> > Second, yes, the return/caret in the block does something but apparently
> not the thing you expected.
> > The effect for caret/^/return is:
> >
> >       ^ statement "Returns the value from statement from the method"
> >
> > The last word is crucial. You return from the method, regardless of the
> block you are in.
> >
> > Like so:
> >
> > fooo
> >
> >  Transcript showln: 'foo 1'.
> >  self bar:
> >    [Transcript showln: 'block 1'.
> >    ^ 1].
> >  Transcript showln: 'foo 2'.
> >  ^ 2.
> >
> >
> > bar: aBlock
> >
> >  Transcript showln: 'bar 1'.
> >  aBlock value.
> >  Transcript showln: 'bar 2'.
> >
> >
> > If you send #foo, transcript will contain
> >
> > foo 1
> > bar 1
> > block 1
> >
> > an the return value will be 1.
> >
> > This is because the Return in the block will return form the _method
> #foo_  (where the block is defined) and not only from the block.
> >
> > What does that have to do with the Workspace???
> >
> > Workspaces create artificial methods for doIts and PrintIts.
> >
> > Hence, your actually sent method looks like that:
> >
> > DoIt
> >  test := [Transcript show: 2;cr. ^2] value
> >
> > If you run that method as print-it, "^2" returns form the DoIt method
> and the workspace can print the 2.
> > If you run that method as print-it, "^2" returns form the DoIt method
> but the assignment has never taken place, so test remains at its previous
> value, wich is nil.
> >
> > I hope this helps.
> >
> > Best regards
> >       -Tobias
> >
> >>
> >> nor does this:
> >>
> >> test :=( [Transcript show: 2;cr. ^2] value) <do it>
> >>
> >> test => nil
> >>
> >> print it still works:
> >>
> >> test := ([Transcript show: 2;cr. ^2] value) => 2
> >>
> >> test => nil.
> >>
> >> In all cases, a 2 appears in the Transcript window, so I know that
> *something* is happening.
> >>
> >> I would have thought that if print-it and  do-it work, then the
> returned value would be put in the test variable, but that is not the case.
> >>
> >> I can use a  workspace global variable to access the output, but that
> kinda makes the ^ a one-trick-pony: useful for breaking out of loops, but
> not giving me access to the return value.
> >>
> >>
> >> [test := 2. Transcript show: test;cr. ^test] value => 2
> >>
> >> test => 2
> >>
> >> Is this an oversight or bug or feature for workspaces, or is it working
> as intended?
> >>
> >>
> >> Lawson
> >>
> >>
> >>
> >
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20221128/1d4f6e7f/attachment-0001.html>


More information about the Squeak-dev mailing list