New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
silence of IterationEnd failures #3147
Comments
From zefram@fysh.orgEven if [perl #126146] and [perl #126147] are not bugs, that .map et When the spec documentation addresses the issue of what values can be -zefram |
From @smlsI'm inclined to reject this ticket, since the implementors (jnthn, lizmat) have already ruled (in the two referenced tickets) that doing anything other than the intended =:= check to an IterationEnd is unsupported and a case of DIHWIDT [1]. Storing IterationEnd in an array or passing it to a &map, would certainly qualify as "doing something other than the intended =:= check" to it, so... just don't do those things. Furthermore, the moved goalpost of this new ticket seems impractical to me. |
The RT System itself - Status changed from 'new' to 'open' |
From zefram@fysh.orgSam S. via RT wrote:
Don't introspect? Don't metaprogram?
I imagine that the check would be performed by whatever puts values For example, a List knows how many elements it has, even if some In the case of map, obviously it can't check its input values, -zefram |
From @smls
Can you describe an actual example of something a Perl 6 module author might want to do that could cause IteratorEnd to be leaked outside of its intended context? Based on jnthn's comments, my understanding is that: 1) The only place that is allowed to return IterationEnd, is the .pull-one method (and friends) of a class that implements the Iterator role. 2) Any code that consumes an Iterator, is responsible for doing the `=:= IteratorEnd` check. I.e. it exists only for this one interface - The supplier side of the interface may generate the sentinel, and the receiving side immediately handles it. It never reaches the "outside world", as long as implementers follow this protocol. (Which we can expect them to, since this is a very low-level API that is only public in order to give module authors who know what they're doing, a way to add low-level functionality to Perl 6 that is compatible with the existing iteration features of the language. So if you want to litter other parts of Perl 6 with (potentially performance-degrading) checks for the sentinel value used in this particular interface, you would certainly bolster your case if you demonstrated how the sentinel value could legitimately end up in those places, or why it would be beneficial to allow it to do so. |
From zefram@fysh.orgSam S. via RT wrote:
Introspect on the CORE:: stash. Perhaps in order to parse code that
So, say, putting the object into a public namespace is an unapproved
If you want to maintain the situation of IterationEnd being reified as
The checks are not free, of course, but they're cheap. As jnthn has -zefram |
From @smls
I gave it a try and you're right, the `IterationEnd` value breaks iterating over the values of that stash: say CORE::.keys.map(*.perl).elems; # 712 That doesn't make it impossible to work with (just make sure you iterate over .keys or .pairs), but I agree that it would be a WAT for someone doing this unsuspectingly.
Maybe you're right, and `IterationEnd` should be a special built-in thing that does not live in `CORE::`? Still, it seems like a contained issue. Or is there anything else other than the `CORE::` object that would leak an `IterationEnd` value into a Seq/List passed to user code? Maybe special-casing the behavior of this object would be easier/cheaper than adding additional checks to all Seq/List producers everywhere. But those discussions are out of my depth... :) |
From zefram@fysh.orgSam S. via RT wrote:
There are some kinds of programming that would be liable to innocently run First, there's MOP stuff, where metaclass code might wrap method calls or In a related vein, think about introspection into the call records of a One can also consider introspection into the non-running code reified -zefram |
This might be a trap or in any case, a documentation issue, not an implementation issue. Moving it to the doc repo. |
I'll try to summarize it here. Since
It does not happen in |
Migrated from rt.perl.org#126163 (status was 'open')
Searchable as RT126163$
The text was updated successfully, but these errors were encountered: