Re^3: Undocumented join() feature, now defunct? (expect)

[tye]

Thank you for your reply

You are most welcome.

but I think you might have misunderstood the direction I'm coming from.

No. I didn't assume you were trying to do any of the things you speculate about (including impacting production code). I was just commenting on your expectations that you explicitly expressed.

My expectation was based on the wording of the documentation which does not explicitly state that EXPR could be evaluated more than once.

Well, EXPR is certainly only evaluated once (per call). But it also didn't explicitly state that the (possibly tied) scalar resulting from EXPR could be accessed more than once.

Of course, it doesn't explicitly state that the scalar might be accessed only once. Documentation doesn't generally (for good reason) specify exactly how many times the implementation might decide to just look at some value you gave to it. Documenting it would mean that you'd be breaking a documented feature if you came up with an optimization that involved just looking at the value one more or one fewer time. It is wise to not tie your implementers' hands so tightly.

Documenting that there is no guarantee as to how many times join() (in particular) might look at the value of one specific argument would be quite silly. Documenting this rather mundane consequence of internal details of implementations changing in a general manner would be fine (and it may already be done somewhere in the Perl docs).

The root problem is your expectation that documentation will mention how many times a value is looked at. It usually doesn't. It shouldn't.

join and "@array" now call FETCH only once on a tied $" [perl #8931].

This answers my question: the behaviour was considered to be a bug which has now been fixed.

But you can tell that it was considered an optimization "bug" not a feature "bug", because no feature documentation was updated to assure users of this detail (so not really a "bug" by how I would use that word, just an optimization). This "behavior" wasn't even nailed down. The comment says "only once" not "exactly once". Based on that comment, how many times will FETCH be called for join( $tied, $one ) ? Maybe 1, maybe 0. Neither choice would be a feature bug. And the answer is fairly likely to change at some point (even if accessing it many times continues to be considered an unfortunate/inefficient implementation choice).

To my mind, an optimization improves performance but does not alter behaviour.

Then I guess you don't have much experience with optimizations. Optimizations very often change subtle behavior. Optimizations should not break feature behavior. How many times the code simply looks at something isn't feature behavior. The fact that using tie makes it possible to notice how many times your variable is looked at doesn't mean that how many times your variable is looked at is something that must be specified and controlled for every feature implementation. Far from it.

Using tie to make a scalar whose value is different every time you look at it isn't hard and certainly can be cute, but it also is fundamentally fragile. And there are tons and tons of optimizations that can have an impact when such is done. That isn't due to a problem with those optimizations. It is due to somebody doing something so fragile. When you do that, you should expect weird stuff and/or be very careful about how you pass that value around.

You most certainly should not expect to not be surprised by the results you get.

[ikegami]

But you can tell that it was considered an optimization "bug" not a feature "bug"

I don't know about this instance specifically, but other operators have similarly been changed as a feature (so the result is more in line with expectations), not as an optimization (thought that's obviously a benefit as well).

However, I completely agree that the developers don't want to be held down by any promises in this area. I would consider the exact number of times a variable is accessed to be subject to change.

[tye]

However, I completely agree that the developers don't want to be held down by any promises in this area. I would consider the exact number of times a variable is accessed to be subject to change.

Thanks. That's the important part. The rest is just quibbles about subtle shades of word meanings.

but other operators have similarly been changed as a feature (so the result is more in line with expectations), not as an optimization

The old behavior can't be what I call a "feature bug" according to ikegami who said:

The old behaviour is correct.

Yes, the improvement can be more than just an optimization. The new behavior can be considered better, but that behavior is not a documented nor documentable feature of join (because that would overly tie developers' hands). Which is what I mean by "not a feature bug".