<br><br><div class="gmail_quote">On Wed, Dec 16, 2009 at 9:44 AM, Lukas Renggli <span dir="ltr"><<a href="mailto:renggli@gmail.com">renggli@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> :) :) This is funny. VisualWorks has exactly the same bug^H^H^Hfeature.<br>
> And if you look at the ANSI standard (ok, this is from the draft, but it is<br>
> essentially the actual document) there is an exception for precisely this<br>
> case, See the last sentence in section 3.4.4 Blocks:<br>
><br>
> If a block has no <block body> or no <statements> in its <block body> then<br>
> the value of the block is undefined.<br>
<br>
</div>Ok, I did not check that document. I somehow expected that all empty<br>
blocks would return nil.<br></blockquote><div><br></div><div>As do we all, which is why this is so horribly broken :) The sad thing is, we've been living with it for thirty years.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> Which allows [] to be implemented as e.g. [Random new next]. In fact both<br>
> VisualWorks and Squeak answer the last argument:<br>
> [:a ] value: 1 1<br>
> [:a :b|] value: 1 value: 2 2<br>
> [:a :b :c :d :e :f :g :h| ] valueWithArguments: (1 to: 8) 8<br>
> [:a | nil] value: 1 nil<br>
> [:a :b| nil] value: 1 value: 2 nil<br>
> At least it is consistent whether the block is inlined or not ;)<br>
> 1+2 ifNotNil: [:arg|] 3<br>
> It as ever been so.<br>
<br>
</div>Thank you for the additional insight. I learned something new on the<br>
Smalltalk semantics today :-)<br>
<br>
I will fix my code then.<br>
<div class="im"><br>
> P.S. I'm caught between wanting to fix it and wanting to let sleeping dogs<br>
> lie. I'd like to know what all the other dialects do. If a substantial<br>
> majority have the same curio I think we have to live with this, uh,<br>
> ornament. Just to be clear, making it a preference is a sick joke on my<br>
> part.<br>
<br>
</div>I think we'd better let it sleep. In my image I have 61 empty blocks<br>
with one or more argument. Some of them might depend on that hidden<br>
behavior.<br>
<br></blockquote><div><br></div><div>I like Peter's response. How about making it a preference? ;) ;) What I mean is we replace the code by something that compiles code that either raises an error or answers nil. y default the preference is set to generate the error code. Then we force people to write [:arg| nil] because [:arg| ] will generate a run-time error (with a verbose and helpful explanatory comment). Then in a few months, years, decades we'll be in a position to remove the preference and generate code that answers nil because all the uses will have been caught.</div>
<div><br></div><div>I can imagine wanting to keep the preference and turning it on when importing code from other dialects for error checking. </div><div><br></div><div>The downside to this approach is that empty blocks with arguments will include the "nil" noise. But that;s very easy to remove automatically once the putsch is stable.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Lukas<br>
<font color="#888888"><br>
--<br>
</font><div><div></div><div class="h5">Lukas Renggli<br>
<a href="http://www.lukas-renggli.ch" target="_blank">http://www.lukas-renggli.ch</a><br>
</div></div></blockquote></div><br>