Hi Christoph,

> On Sep 14, 2020, at 5:17 AM, Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:
> 
> Hi all,
> 
> I just evaluated the following line and was surprised by the result:
> 
> Compiler evaluate: '' for: 42.
> 
> The answer was nil, whereas I rather would have expected the answer to life the universe and everything 42, as it is the case for full methods compiled on an object. What do you think about this, which should be the right output?
> 
> I was even more surprised after taking a look into the relevant Parser implementation, which is #statements:innerBlock:blockNode:. Actually, the 'inner' argument's sole purpose is to use 'nil' instead of 'self' as a return value if there are zero statements. If we would not like to have this extra rule for doIt snippets, we would only have to change #method:context:[encoder:] and pass 'false' instead of 'doit' to #statements:innerBlock:.
> 
> I'm probably missing some logical consequences of the syntactic concept of blocks, methods, and doits, so I would like to hear your thoughts on this.
> 

Smells like my bug.  I agree with you that the null statement should evaluate to self at method level.  IIRC, the ANSI standard says that the null statement evaluated to the last block argument did blocks with arguments (to legalize a quirk in Peter Deutsch’s closure compiler for ObjectWorks 2.5 and subsequent).  And clearly the null statement in a block evaluates to nil.  I hunk that the null statement should evaluate to self at method level and nil at block level, irrespective of the number of block arguments.

To be clear I would have these tests

self assert: (Compiler evaluate: '' for: 42) equals: 42.
self assert: ([:arg|] value: 42) equals: nil.
self assert: [] value equals: nil.

> Best,
> 
> Christoph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200914/c47abc45/attachment.html>