"Can't optimize #repeat" warning

This applies to D3 & D4.  When compiling a method containing the selector
#repeat, the warning "Can't optimize #repeat" is displayed.  Also, if an
attempt is made to send an object the message #repeat in a workspace or
inspector, a warning dialog is displayed prior to the object receiving the
message.

The warnings are a bit annoying.  Is there any chance of getting them
removed in a future release or adding a system parameter that would allow
them to be suppressed?

Thanks.

Chris

"Chris Hayes" <[hidden email]> wrote:

#repeat expects a block for a reciever. Here is an example:

| aArr ix elem |
aArr := #(1 2 3 4).
ix := 1.
[  elem := aArr at: ix ifAbsent: [^elem]. ix := ix + 1] repeat.

Costas

"Costas Menico" <[hidden email]> wrote in message
news:[hidden email]...
> "Chris Hayes" <[hidden email]> wrote:
>
> >This applies to D3 & D4.  When compiling a method containing the selector
> >#repeat, the warning "Can't optimize #repeat" is displayed.  Also, if an
> >attempt is made to send an object the message #repeat in a workspace or
> >inspector, a warning dialog is displayed prior to the object receiving
the
I'm not sure I understand what it means for a selector to expect a certain
type of receiver (e.g., #repeat expecting a block).  The *receiver* either
understands a message or it doesn't.  It appears, however, that the Dolphin
compiler can perform some optimizations if it determines that the receiver
of #repeat is a niladic block.

Anyway, in the scenario I'm describing, a BlockClosure is not the receiver
(Sorry. I should have mentioned this in my original post).  The message is
being sent to an instance of a class of mine that implements a method named
#repeat.

Chris

Chris,

> Anyway, in the scenario I'm describing, a BlockClosure is not the receiver
> (Sorry. I should have mentioned this in my original post).  The message is
> being sent to an instance of a class of mine that implements a method
named
> #repeat.

I think you should just treat the #repeat selector as a sort of reserved
word in Dolphin. There are a number of such selectors, #ifTrue and #isNil
are other examples, that are recognised and given special treatment by the
compiler. Using them as normal selectors in another class is probably not
such a good idea and in some cases (#isNil for example) just won't work.

Ian

"Ian Bartholomew" <[hidden email]> wrote in message
news:93i87j$mtc$[hidden email]...
> Chris,
>

> I think you should just treat the #repeat selector as a sort of reserved
> word in Dolphin. There are a number of such selectors, #ifTrue and #isNil
> are other examples, that are recognised and given special treatment by the
> compiler. Using them as normal selectors in another class is probably not
> such a good idea and in some cases (#isNil for example) just won't work.
>
> Ian

I don't understand why it's not a good idea to implement a method like
#repeat.  The sending method compiles correctly and executes correctly.  The
only difference is that the compiler came across a special selector, looked
to see if it could perform an optimization, and found that it couldn't.
That's fine.  It's not clear to me, however, why I, as a developer, need to
be informed of this via a warning message or dialog.  I wasn't really
expecting it to be optimized.  Are there other problems lurking here that I
need to be aware of?

On the other hand, I definitely want to be notified in the cases where
execution will fail (#isNil).

Chris

Chris,

> I don't understand why it's not a good idea to implement a method like
> #repeat.  The sending method compiles correctly and executes correctly.
The
> only difference is that the compiler came across a special selector,
looked
> to see if it could perform an optimization, and found that it couldn't.
> That's fine.  It's not clear to me, however, why I, as a developer, need
to
> be informed of this via a warning message or dialog.  I wasn't really
> expecting it to be optimized.  Are there other problems lurking here that
I
> need to be aware of?

It's just that I feel you are taking an unnecessary risk by using a selector
that you know is used by the image in a special way. In the future OA might
decide that the #repeat selector is a bottleneck when used with blocks and
inline it in the same way as #isNil. All your code that uses #repeat will
then either break of just stop working as your #repeat method is never
reached.

> On the other hand, I definitely want to be notified in the cases where
> execution will fail (#isNil).

I think this is just one of those swings and roundabout things that you get
with Smalltalk. The advantage is that you can override existing methods at
any level to change the behaviour of the image. The disadvantage is that
sometimes it doesn't go as expected - either against you as in overriding
#isNil or against the image as (for example) in overriding #class to do
something other than answering the Class of the receiver.  OA could add
warnings if a "reserved" selector was used in a user class but I'm not sure
that the annoyance this creates by warning when you override a method
intentionally would outweigh the rare (IMHO) occasions when you reuse a
selector unintentionally.

Personally I just try to avoid reusing selectors used by any of the main
system classes unless I want to override that methods behaviour. It makes
life simpler <g>

Ian

Chris

You wrote in message news:93ja15$afgag$[hidden email]...
> ...
> I don't understand why it's not a good idea to implement a method like
> #repeat.  ...  It's not clear to me, however, why I, as a developer, need
to
> be informed of this via a warning message or dialog.  I wasn't really
> expecting it to be optimized.  Are there other problems lurking here that
I
> need to be aware of?

Yes.
1) It may not port - we have chosen to optimize repeat only where the
receiver is a literal block, but that may not be true of all ANSI conforming
implementations. #repeat is a special selector which the standard allows to
be expanded in-line, and it doesn't have to be "sent" as a message.
2) It may cause cognitive dissonance on the part of other Smalltalk
programmers attempting to read the code.

Of these I think (2) is a bigger concern (code being read more often than it
is ported). The fact that #repeat is indicating a control structure is
entrenched, use it for other purposes at the risk of confusing others.

> On the other hand, I definitely want to be notified in the cases where
> execution will fail (#isNil).

It's true that there is a difference. Since it wouldn't make much sense to
optimize isNil out only in cases where the receiver was a literal (!), it is
always optimized. In the case of #repeat we can identify the cases where
in-line expansion will be useful, and generate a normal message send in
other cases. The warning is there to inform you that (a) it is quite likely
you intended to use #repeat to form a loop, but made an error and uses round
brackets instead of square ones (unlikely, you might say, but I do this on
an irregular basis with #whileTrue), (b) it isn't a good idea because
#repeat does have a status as a quasi reserved word.

Regards

Blair