On Wed, Dec 16, 2009 at 9:44 AM, Lukas Renggli <renggli at gmail.com> wrote:

> > :) :)  This is funny.  VisualWorks has exactly the same bug^H^H^Hfeature.
> >  And if you look at the ANSI standard (ok, this is from the draft, but it
> is
> > essentially the actual document) there is an exception for precisely this
> > case,  See the last sentence in section 3.4.4 Blocks:
> >
> > If a block has no <block body> or no <statements> in its <block body>
> then
> > the value of the block is undefined.
>
> Ok, I did not check that document. I somehow expected that all empty
> blocks would return nil.
>

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.


>
> > Which allows [] to be implemented as e.g. [Random new next].  In fact
> both
> > VisualWorks and Squeak answer the last argument:
> > [:a ] value: 1 1
> > [:a :b|] value: 1 value: 2 2
> > [:a :b :c :d :e :f :g :h| ] valueWithArguments: (1 to: 8) 8
> > [:a | nil] value: 1 nil
> > [:a :b| nil] value: 1 value: 2 nil
> > At least it is consistent whether the block is inlined or not ;)
> > 1+2 ifNotNil: [:arg|] 3
> > It as ever been so.
>
> Thank you for the additional insight. I learned something new on the
> Smalltalk semantics today :-)
>
> I will fix my code then.
>
> > P.S.  I'm caught between wanting to fix it and wanting to let sleeping
> dogs
> > lie.  I'd like to know what all the other dialects do.  If a substantial
> > majority have the same curio I think we have to live with this, uh,
> > ornament.  Just to be clear, making it a preference is a sick joke on my
> > part.
>
> I think we'd better let it sleep. In my image I have 61 empty blocks
> with one or more argument. Some of them might depend on that hidden
> behavior.
>
>
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.

I can imagine wanting to keep the preference and turning it on when
importing code from other dialects for error checking.

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.


> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091216/d0b85217/attachment.htm