Front page | perl.perl5.porters |
Postings from August 2012
On 25 August 2012 01:53, Damian Conway <damian@conway.org> wrote: > Hugo wrote: > >> This is the bit I'm really not convinced about. I feel there is >> a significant difference between the language that has this: >> my($value) = ($line =~ /value=(\d+)/); # yay, we got a number >> >> and the one that has this: >> my($value) = ($line =~ /value=(\d+)/); # yay, we got a number >> $value += 0; # RT#314159: oops, *now* we got a number >> >> The first of these expresses much that to me seems intrinsic to what >> perl is. The second seems to throw out the DWIM with the bathwater. > > No-one (I hope!) is proposing that Perl's auto-coercions be eliminated, > or modified in any way. Perish the thought! > > All I was saying was that smartmatching works by knowing what type the > RHS argument is (a sub ref, a regex ref, a number, a string, an object) > and then picking the appropriate comparison operator on that basis. > > The problem with that is that Perl itself doesn't *always* know what the > RHS argument is. Or, rather, it doesn't remember what the RHS is in a > single specific case: when the RHS is a simple variable that has > previously been autocoerced. > > As I'm certain Hugo fully understands (but others may not), that's simply > because, during an auto-coercion, Perl caches the conversion for > efficiency. So when smartmatch looks inside a post-autocoerced variable > it no longer sees a pure IV, UV, NV (in the case of a stored number) or > a pure PV (in the case of a stored string), but rather sees the original > storage replaced by a "dualvar" PVIV, PVUV, or PVNV. Which means the > smartmatching mechanism can no longer tell what kind of value the > original value was. > > If the original caching mechanism had been implemented so that > autocoercions installed (say) a PVplusIV (for a string with cached integer > autocoercion) or an IVplusPV (for an integer with cached string > autocoercion), then we would have no problem. Smartmatch would be able > to tell what was "really" in the variable, and what was merely a cached > optimization for repeated autocoercions. > > (And, BTW, if that original type information were retained, the weird > history-dependent behaviour of the bitwise operators could likewise be fixed.) > > In other words, the current implementation of variables loses type > information as a side-effect of autocoercion. But smartmatch needs that > type information to DWIM in the one special case of a variable as its RHS. > > The various positions on this issue seem to be: > > Option 1: In that one case, as smartmatching cannot DWIM, it should > fail loudly (and we should look at having vars somehow > preserve knowledge about what type they were originally > assigned, so that this one problematic case will eventually > go away). > > Option 2. In that one case, smartmatching should fall back to > eq-matching, since that's somehow more general. > > Option 4. That one case indicates smartmatching is inherently > incompatible with Perl and should be removed entirely. > > Personally, I still believe Option 1 is the right answer, and that > smartmatching is not some terrible threat to the intrinsic nature of > Perl, but rather an important missing piece of its toolkit. :-) > > Perl has plenty of values that DWIM for operators which SWIM; > smartmatching adds an operator that DWIMs for values which SWIM. > > And that's not only useful...it's also very Perlish. Just in a new way. Could I just add I hope that the missing Option 3 is to fix the underlying bit flag operations as per Chips patch (plus more love if its needed) and then re-asses smartmatch once it is done? We have a patch to get us started, so this isn't hypothetical code at all. For reasons of my own (related to serialization) I would like to have this issue fixed, and will put some time into it if needed. (Although I find it hard to believe I could do better than Chip.) Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next