develooper Front page | perl.perl5.porters | Postings from August 2012

RE: fixing smartmatch just hard enough (and when, too)

Thread Previous | Thread Next
From:
Jan Dubois
Date:
August 24, 2012 17:23
Subject:
RE: fixing smartmatch just hard enough (and when, too)
Message ID:
044301cd8257$cf80c1e0$6e8245a0$@activestate.com
On Fri, 24 Aug 2012, Damian Conway 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!

[... a lot of text explaining how auto-coercion may lose the original type ...]

I don't understand how this applies to Hugo's example above.

You are arguing that Perl variables should be either a number or a
string. Hugo is saying that they are both at the same time, until you
use them as one or the other. Think of it a little bit like wave-
particle duality: a photon doesn't start out as a particle or wave. It
exists as both, until an observation forces it to be one or the other.

To get back on topic, and Hugo's example:

   my($value) = ($line =~ /value=(\d+)/);  # yay, we got a number

So should $value be "originally" a string or a number?  Having to
decide this before $value is used in an operation is the part that
doesn't really fit into Perl 5.

> 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.

So how would Hugo's example work with this "fixed" type system? How
would it know that it has to treat $value as a number? <kidding>By
storing capture groups that only contain \d+ as SvIV?</kidding> I
maintain that we would still have a problem even if autocoercions were
changed in the way you describe.

Cheers,
-Jan


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About