| |
 Search this list this category for: (Advanced)

Mailing List Archive: Perl: porters

# Newline legacy (Was: fixing smartmatch just hard enough (and when, too))

 1 2 3  View All Index | Next | Previous | Print Thread | View Threaded

jvromans at squirrel

Aug 20, 2012, 11:33 AM

Post #1 of 55 (221 views)
 Newline legacy (Was: fixing smartmatch just hard enough (and when, too))
[Quoting demerphq, on August 20 2012, 19:24, in "Re: fixing smartmatc"]
> But perl considers "1" numerically equvalent to "1\n", and as far as I
> can tell without warning either:

Perl also happily considers "\n\n\n 001 \n \t\r \r\n" to be "1".
I've always wondered whether that was a good idea.

And, indirecty, this has led to the \$ \z \Z uglyness.

-- Johan

jand at activestate

Aug 20, 2012, 12:32 PM

Post #2 of 55 (212 views)
 RE: Newline legacy (Was: fixing smartmatch just hard enough (and when, too)) [In reply to]
On Mon, 20 Aug 2012, jvromans [at] squirrel wrote:
> [Quoting demerphq, on August 20 2012, 19:24, in "Re: fixing smartmatc"]
> > But perl considers "1" numerically equvalent to "1\n", and as far as I
> > can tell without warning either:
>
> Perl also happily considers "\n\n\n 001 \n \t\r \r\n" to be "1".
> I've always wondered whether that was a good idea.

Given that even "1a" is considered to be the same as "1" (numerically),
it totally makes sense that your constructed string is numerically equal
as well.

The question is just whether it should warn or not. I don't think we
would want to warn on leading spaces or zeros: "001" and " 1" should be
equal to "1" because they may just be extracted from a document with
substr(\$line, \$offset, 3).

Given that numbers may be left-aligned, we may want to also allow
trailing spaces. And a trailing newline, in case we extract from the
end of the line, and it is missing the trailing space padding.
On Windows we may also want to include a trailing "\r\n".

From here to allowing arbitrary leading and trailing whitespace is
just a small step, but I doubt it matter much. In the end we are
only talking about a warning, so it is always a compromise.

> And, indirecty, this has led to the \$ \z \Z uglyness.

No, it is a separate issue. :)

Cheers,
-Jan

j.imrie1 at virginmedia

Aug 20, 2012, 1:56 PM

Post #3 of 55 (212 views)
 Re: Newline legacy (Was: fixing smartmatch just hard enough (and when, too)) [In reply to]
On 20/08/2012 20:32, Jan Dubois wrote:
[Snip]
> Given that numbers may be left-aligned, we may want to also allow
> trailing spaces. And a trailing newline, in case we extract from the
> end of the line, and it is missing the trailing space padding. On
> Windows we may also want to include a trailing "\r\n". From here to
> allowing arbitrary leading and trailing whitespace is just a small
> step, but I doubt it matter much. In the end we are only talking about
> a warning, so it is always a compromise.

If you want to be matching new lines shouldn't you be matching against \R

John

jand at activestate

Aug 20, 2012, 2:07 PM

Post #4 of 55 (213 views)
 RE: Newline legacy (Was: fixing smartmatch just hard enough (and when, too)) [In reply to]
On Mon, 20 Aug 2012, John Imrie wrote:
> On 20/08/2012 20:32, Jan Dubois wrote: [Snip]
> > Given that numbers may be left-aligned, we may want to also allow
> > trailing spaces. And a trailing newline, in case we extract from the
> > end of the line, and it is missing the trailing space padding. On
> > Windows we may also want to include a trailing "\r\n". From here to
> > allowing arbitrary leading and trailing whitespace is just a small
> > step, but I doubt it matter much. In the end we are only talking
> > about a warning, so it is always a compromise.
>
> If you want to be matching new lines shouldn't you be matching
> against \R

I don't want to match newlines, I just want to sum up a column of
data without getting a warning:

\$sum += substr(\$line, 45, 8) while defined(\$line = <>);

while (defined(\$line = <>)) {
chomp \$line;
my \$field = substr(\$line, 45, 8);
\$field =~ s/^\s*(\S+)\s*/\$1/;
\$sum += \$field;
}

You know, when you use Perl as a better awk. :)

DWIM. Well, at least for me that is part of the charm of Perl. It is not
just Python with additional braces and punctuation character...

Cheers,
-Jan

xdaveg at gmail

Aug 20, 2012, 5:07 PM

Post #5 of 55 (211 views)
 Re: Newline legacy (Was: fixing smartmatch just hard enough (and when, too)) [In reply to]
On Mon, Aug 20, 2012 at 5:07 PM, Jan Dubois <jand [at] activestate> wrote:

>
> \$sum += substr(\$line, 45, 8) while defined(\$line = <>);
>

TIMTOWTDI: I generally tend to approach that in map/grep style if I can.

\$ perl -MList::Util=sum -wE 'say sum map{ /^\s*(\S+)\s*\$/ } map { substr
\$_, 45, 8 } <>' file.txt

Could probably throw a grep { defined } in there if necessary. And there
are CPAN modules for the whitespace trimming for even less hassle.

I think there was debate in the past about adding a trim() into core. I'm
often tempted by it -- another case where loading a CPAN module to do
something common and trivial is annoying.

But as to smartmatch -- I don't think I'd want it to be so smart. Or
rather, I want the "smart" to mean allowing a variety of comparator
functions, not smart as in "I'm going to guess how you want to interpret a
value as a string/number/without-whitespace, etc.".

-- David

-- David

damian at conway

Aug 20, 2012, 5:59 PM

Post #6 of 55 (211 views)
 Re: Newline legacy (Was: fixing smartmatch just hard enough (and when, too)) [In reply to]
David Golden commented:

> But as to smartmatch -- I don't think I'd want it to be so smart. Or
> rather, I want the "smart" to mean allowing a variety of comparator
> functions, not smart as in "I'm going to guess how you want to interpret a
> value as a string/number/without-whitespace, etc.".

Ideally, the numeric case in the smartmatch table would work like this:

Any Num numeric comparison \$a == \$b

That is: if the RHS operand is categorically a number, unconditionally
do numeric comparison.

Then there wouldn't be any guesswork. They explicitly said "match
against a number",
so we naturally match numerically.

And, because 'when X' is (I hope!) becoming uncategorically '\$_ ~~ X', then:

when 0 {...}

would also work correctly, even on unchomped input:
they said "match against the number 0", so we match numerically.

And if they wanted eq matching for that, they'd write:

when "0" {...}

The problem is that everyone tells me that's not possible in Perl 5.
I'm still not certain why.

I *suspect* it's because it's complicated to distinguish the right
behaviour for:

\$num = 0;
say \$num;
say \$something ~~ \$num;

as, after having been used as a string, the contents of \$num have both
string and
number internal representations.

If that is indeed the problem, maybe it would be sufficient to make it
so that if the RHS operand to a smartmatch has an internal numeric
representation, it always uses ==, even if there's also an internal
string representation. But I guess that has DWIM problems too:

\$str = "0";
say 0+\$str;
say \$something ~~ \$str; # Now uses == :-(

Sigh.

Or, perhaps, we could define smartmatch to use == if the RHS operand *only*
has a numeric representation (i.e. no internal string representation),
in which case you would get:

\$num = 0;

\$something ~~ \$num # uses == (no internal string rep)
\$something ~~ "0" # always eq
\$something ~~ 0 # always ==
\$something ~~ "\$num" # always eq
\$something ~~ \$num # now uses eq :-( has internal string rep )
\$something ~~ 0+\$num # always uses ==
\$something ~~ 2*\$num # always uses ==
\$something ~~ length(\$num) # always uses ==
# etc.

That's much less bad, I feel: most cases then just DWIM. The only issue
is that you always need to prefix a variable-as-right-operand with '0+'
if you want to ensure that it uses numeric comparison.

Would that be a feasible solution?

Damian

xdaveg at gmail

Aug 20, 2012, 8:28 PM

Post #7 of 55 (211 views)
 Re: Newline legacy (Was: fixing smartmatch just hard enough (and when, too)) [In reply to]
On Mon, Aug 20, 2012 at 8:59 PM, Damian Conway <damian [at] conway> wrote:

> when 0 {...}
>
> when "0" {...}
>
> The problem is that everyone tells me that's not possible in Perl 5.
> I'm still not certain why.
>
>
I suspect it can be made to work for constants, but variables are harder as
you point out. Though I think Chip just did some work to help track what
it was originally.

> Or, perhaps, we could define smartmatch to use == if the RHS operand *only*
> has a numeric representation (i.e. no internal string representation),
> in which case you would get:
>
>
That seems reasonable to me.

-- David

demerphq at gmail

Aug 21, 2012, 1:28 AM

Post #8 of 55 (211 views)
 Re: Newline legacy (Was: fixing smartmatch just hard enough (and when, too)) [In reply to]
On 21 August 2012 02:07, David Golden <xdaveg [at] gmail> wrote:
> I think there was debate in the past about adding a trim() into core. I'm
> often tempted by it -- another case where loading a CPAN module to do
> something common and trivial is annoying.

Yeah, at \$work we have seen significant performance gains by writing a
trim function in XS. It is a surprising cause of slowdown, and regexes
perform extremely badly at the end of a string.

It has always been on my todo list to special case:

s/\A\s+//;
s/\s+\z//;

and

s/\A\s+|\s+\z//g;

into an internal trim. The only problem is it is much easier to write
XS code to do this than it is to figure out how to optimize these
constructs.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

doy at tozt

Aug 21, 2012, 6:21 AM

Post #9 of 55 (211 views)
 Re: Newline legacy (Was: fixing smartmatch just hard enough (and when, too)) [In reply to]
On Tue, Aug 21, 2012 at 10:59:05AM +1000, Damian Conway wrote:
> David Golden commented:
>
> > But as to smartmatch -- I don't think I'd want it to be so smart. Or
> > rather, I want the "smart" to mean allowing a variety of comparator
> > functions, not smart as in "I'm going to guess how you want to interpret a
> > value as a string/number/without-whitespace, etc.".
>
> Or, perhaps, we could define smartmatch to use == if the RHS operand *only*
> has a numeric representation (i.e. no internal string representation),
> in which case you would get:
>
> \$num = 0;
>
> \$something ~~ \$num # uses == (no internal string rep)
> \$something ~~ "0" # always eq
> \$something ~~ 0 # always ==
> \$something ~~ "\$num" # always eq
> \$something ~~ \$num # now uses eq :-( has internal string rep )
> \$something ~~ 0+\$num # always uses ==
> \$something ~~ 2*\$num # always uses ==
> \$something ~~ length(\$num) # always uses ==
> # etc.
>
> That's much less bad, I feel: most cases then just DWIM. The only issue
> is that you always need to prefix a variable-as-right-operand with '0+'
> if you want to ensure that it uses numeric comparison.
>
> Would that be a feasible solution?

I think this is a much better solution than "looks like a number".

-doy

mpeters at plusthree

Aug 21, 2012, 6:32 AM

Post #10 of 55 (212 views)
 Re: Newline legacy (Was: fixing smartmatch just hard enough (and when, too)) [In reply to]
On 08/21/2012 09:21 AM, Jesse Luehrs wrote:

>> \$num = 0;
>>
>> \$something ~~ \$num # uses == (no internal string rep)
>> \$something ~~ "0" # always eq
>> \$something ~~ 0 # always ==
>> \$something ~~ "\$num" # always eq
>> \$something ~~ \$num # now uses eq :-( has internal string rep )
>> \$something ~~ 0+\$num # always uses ==
>> \$something ~~ 2*\$num # always uses ==
>> \$something ~~ length(\$num) # always uses ==
>> # etc.
>>
>> That's much less bad, I feel: most cases then just DWIM. The only issue
>> is that you always need to prefix a variable-as-right-operand with '0+'
>> if you want to ensure that it uses numeric comparison.
>>
>> Would that be a feasible solution?
>
> I think this is a much better solution than "looks like a number".

While a part of me likes this, a part of me looks at it and says, this
is one of my problems with JavaScript. + in JavaScript does different
things based on what's in the variables and it can be really confusing
in part of code when you have "num1 + num2" and you don't know whether
that's doing addition or string concatenation and you have to trace back
through the code to find out.

This isn't quite as bad since it's just switching between 2 equality
operators, but still it's weird that how you've used a variable before
will impact which operator is used later.

--
Michael Peters
Plus Three, LP

doy at tozt

Aug 21, 2012, 6:39 AM

Post #11 of 55 (211 views)
 Re: Newline legacy (Was: fixing smartmatch just hard enough (and when, too)) [In reply to]
On Tue, Aug 21, 2012 at 09:32:48AM -0400, Michael Peters wrote:
> On 08/21/2012 09:21 AM, Jesse Luehrs wrote:
>
> >> \$num = 0;
> >>
> >> \$something ~~ \$num # uses == (no internal string rep)
> >> \$something ~~ "0" # always eq
> >> \$something ~~ 0 # always ==
> >> \$something ~~ "\$num" # always eq
> >> \$something ~~ \$num # now uses eq :-( has internal string rep )
> >> \$something ~~ 0+\$num # always uses ==
> >> \$something ~~ 2*\$num # always uses ==
> >> \$something ~~ length(\$num) # always uses ==
> >> # etc.
> >>
> >>That's much less bad, I feel: most cases then just DWIM. The only issue
> >>is that you always need to prefix a variable-as-right-operand with '0+'
> >>if you want to ensure that it uses numeric comparison.
> >>
> >>Would that be a feasible solution?
> >
> >I think this is a much better solution than "looks like a number".
>
> While a part of me likes this, a part of me looks at it and says,
> this is one of my problems with JavaScript. + in JavaScript does
> different things based on what's in the variables and it can be
> really confusing in part of code when you have "num1 + num2" and you
> don't know whether that's doing addition or string concatenation and
> you have to trace back through the code to find out.
>
> This isn't quite as bad since it's just switching between 2 equality
> operators, but still it's weird that how you've used a variable
> before will impact which operator is used later.

Well, no, that's what the "looks like a number" solution would do. The
whole idea here is that you can be explicit about which form of matching
that you want, by either doing 'when (0+\$foo)' or 'when ("\$foo")'
depending on if you want numeric or string matching.

-doy

mpeters at plusthree

Aug 21, 2012, 6:40 AM

Post #12 of 55 (211 views)
 Re: Newline legacy (Was: fixing smartmatch just hard enough (and when, too)) [In reply to]
On 08/21/2012 09:32 AM, Michael Peters wrote:

> While a part of me likes this, a part of me looks at it and says, this
> is one of my problems with JavaScript. + in JavaScript does different
> things based on what's in the variables and it can be really confusing
> in part of code when you have "num1 + num2" and you don't know whether
> that's doing addition or string concatenation and you have to trace back
> through the code to find out.
>
> This isn't quite as bad since it's just switching between 2 equality
> operators, but still it's weird that how you've used a variable before
> will impact which operator is used later.

But at the same time, you still have complete control. If you always
want string comparison you do

\$something ~~ '' . \$var

If you always want numeric comparison you do:

\$something ~~ 0 + \$var

(or use a literal)

\$something ~~ 15

But still, the fact that you need to always use C<'' . \$var> to get
string comparison seems like it defeats the point of having it default
to string comparison since you can't control how the variable's been
used before.

--
Michael Peters
Plus Three, LP

bmb at mail

Aug 21, 2012, 9:46 AM

Post #13 of 55 (214 views)
 Re: Newline legacy (Was: fixing smartmatch just hard enough (and when, too)) [In reply to]
On 8/20/12, Damian Conway <damian [at] conway> wrote:
> Or, perhaps, we could define smartmatch to use == if the RHS operand *only*
> has a numeric representation (i.e. no internal string representation),
> in which case you would get:
>
> \$num = 0;
>
> \$something ~~ \$num # uses == (no internal string rep)
> \$something ~~ "0" # always eq
> \$something ~~ 0 # always ==
> \$something ~~ "\$num" # always eq
> \$something ~~ \$num # now uses eq :-( has internal string rep
> )

In this case (RHS is a scalar with an internal string rep) would it be
too weird to use eq and if it fails and \$num looks like a number, then
use ==?

> \$something ~~ 0+\$num # always uses ==
> \$something ~~ 2*\$num # always uses ==
> \$something ~~ length(\$num) # always uses ==
> # etc.
>
> That's much less bad, I feel: most cases then just DWIM. The only issue
> is that you always need to prefix a variable-as-right-operand with '0+'
> if you want to ensure that it uses numeric comparison.

--

klaus03 at gmail

Aug 21, 2012, 9:56 AM

Post #14 of 55 (211 views)
 Re: Newline legacy (Was: fixing smartmatch just hard enough (and when, too)) [In reply to]
On 21 août, 15:40, mpet...@plusthree.com (Michael Peters) wrote:
> On 08/21/2012 09:32 AM, Michael Peters wrote:
>
> > While a part of me likes this, a part of me looks at it and says, this
> > is one of my problems with JavaScript. + in JavaScript does different
> > things based on what's in the variables and it can be really confusing
> > in part of code when you have "num1 + num2" and you don't know whether
> > that's doing addition or string concatenation and you have to trace back
> > through the code to find out.
>
> > This isn't quite as bad since it's just switching between 2 equality
> > operators, but still it's weird that how you've used a variable before
> > will impact which operator is used later.
>
> But at the same time, you still have complete control. If you always
> want string comparison you do
>
>    \$something ~~ '' . \$var

That's not quite correct, if you always want string comparison, you
need to manipulate the left operand as well:

'' . \$something ~~ '' . \$var

doy at tozt

Aug 21, 2012, 10:02 AM

Post #15 of 55 (211 views)
 Re: Newline legacy (Was: fixing smartmatch just hard enough (and when, too)) [In reply to]
On Tue, Aug 21, 2012 at 09:56:13AM -0700, Klaus wrote:
> On 21 août, 15:40, mpet...@plusthree.com (Michael Peters) wrote:
> > On 08/21/2012 09:32 AM, Michael Peters wrote:
> >
> > > While a part of me likes this, a part of me looks at it and says, this
> > > is one of my problems with JavaScript. + in JavaScript does different
> > > things based on what's in the variables and it can be really confusing
> > > in part of code when you have "num1 + num2" and you don't know whether
> > > that's doing addition or string concatenation and you have to trace back
> > > through the code to find out.
> >
> > > This isn't quite as bad since it's just switching between 2 equality
> > > operators, but still it's weird that how you've used a variable before
> > > will impact which operator is used later.
> >
> > But at the same time, you still have complete control. If you always
> > want string comparison you do
> >
> >    \$something ~~ '' . \$var
>
> That's not quite correct, if you always want string comparison, you
> need to manipulate the left operand as well:
>
> '' . \$something ~~ '' . \$var

behavior for the left operand.

-doy

doy at tozt

Aug 21, 2012, 10:03 AM

Post #16 of 55 (211 views)
 Re: Newline legacy (Was: fixing smartmatch just hard enough (and when, too)) [In reply to]
On Tue, Aug 21, 2012 at 12:46:43PM -0400, Brad Baxter wrote:
> On 8/20/12, Damian Conway <damian [at] conway> wrote:
> > Or, perhaps, we could define smartmatch to use == if the RHS operand *only*
> > has a numeric representation (i.e. no internal string representation),
> > in which case you would get:
> >
> > \$num = 0;
> >
> > \$something ~~ \$num # uses == (no internal string rep)
> > \$something ~~ "0" # always eq
> > \$something ~~ 0 # always ==
> > \$something ~~ "\$num" # always eq
> > \$something ~~ \$num # now uses eq :-( has internal string rep
> > )
>
> In this case (RHS is a scalar with an internal string rep) would it be
> too weird to use eq and if it fails and \$num looks like a number, then
> use ==?

Yes - this would still make things unpredictable in certain cases.

-doy

david at justatheory

Aug 21, 2012, 10:03 AM

Post #17 of 55 (211 views)
 Re: Newline legacy (Was: fixing smartmatch just hard enough (and when, too)) [In reply to]
On Aug 20, 2012, at 2:07 PM, Jan Dubois wrote:

> I don't want to match newlines, I just want to sum up a column of
> data without getting a warning:
>
> \$sum += substr(\$line, 45, 8) while defined(\$line = <>);
>
>
> while (defined(\$line = <>)) {
> chomp \$line;
> my \$field = substr(\$line, 45, 8);
> \$field =~ s/^\s*(\S+)\s*/\$1/;
> \$sum += \$field;
> }
>
> You know, when you use Perl as a better awk. :)
>
> DWIM. Well, at least for me that is part of the charm of Perl. It is not
> just Python with additional braces and punctuation character...

A bit OT, but I wonder how hard it would be to add modifiers to the <> operator? If I want each line chomped, maybe it'd be something like:

while (<>c)

Or

while (c<>)

The latter is a syntax error, so there would be no compatibility issues. Not sure if other flags might be useful.

Just a passing idea.

Best,

David

doy at tozt

Aug 21, 2012, 10:07 AM

Post #18 of 55 (211 views)
 Re: Newline legacy (Was: fixing smartmatch just hard enough (and when, too)) [In reply to]
On Tue, Aug 21, 2012 at 10:03:40AM -0700, David E. Wheeler wrote:
> On Aug 20, 2012, at 2:07 PM, Jan Dubois wrote:
>
> > I don't want to match newlines, I just want to sum up a column of
> > data without getting a warning:
> >
> > \$sum += substr(\$line, 45, 8) while defined(\$line = <>);
> >
> >
> > while (defined(\$line = <>)) {
> > chomp \$line;
> > my \$field = substr(\$line, 45, 8);
> > \$field =~ s/^\s*(\S+)\s*/\$1/;
> > \$sum += \$field;
> > }
> >
> > You know, when you use Perl as a better awk. :)
> >
> > DWIM. Well, at least for me that is part of the charm of Perl. It is not
> > just Python with additional braces and punctuation character...
>
> A bit OT, but I wonder how hard it would be to add modifiers to the <> operator? If I want each line chomped, maybe it'd be something like:
>
> while (<>c)
>
> Or
>
> while (c<>)
>
> The latter is a syntax error, so there would be no compatibility issues. Not sure if other flags might be useful.
>
> Just a passing idea.

Or even just "while (chomp(<>))", where "chomp" could be an arbitrary
function. It'd be more useful if it was more easily extensible.

-doy

alex at earth

Aug 21, 2012, 4:03 PM

Post #19 of 55 (211 views)
 Re: Newline legacy (Was: fixing smartmatch just hard enough (and when, too)) [In reply to]
a) I massively support simplifying smartmatch, because it is currently
smarter than me, and I've never been confident of what it will do with
anything to use it.

#### [Tue, Aug 21, 2012 at 09:40:28AM -0400: Michael Peters]
>
> But at the same time, you still have complete control. If you always
> want string comparison you do
>
> \$something ~~ '' . \$var
>
> If you always want numeric comparison you do:
>
> \$something ~~ 0 + \$var
>
> (or use a literal)
>
> \$something ~~ 15

b) Or just don't smart match. If you want numeric comparison you use
==, if you want string comparison you use eq, Perl has always treated
numbers and strings differently and we will not be able to unify our
treatment of them without introducing some horrible edge case that
confuses me out of using ~~. In fact, using ~~ for

Scalar ~~ Scalar

should probably not be supported because it's inherently ambigious,
and therefore dumb.

This also affects `when (Scalar)', which should
require you to inform when() which of eq and == you really mean,
as otherwise we're introducing heisenbugs.

Alex
--
HISTORY: Papa Hegel he say that all we learn from history is that we
learn nothing from history. I know people who can't even learn from
what happened this morning. Hegel must have been taking the long view.

xdaveg at gmail

Aug 21, 2012, 4:11 PM

Post #20 of 55 (212 views)
 Re: Newline legacy (Was: fixing smartmatch just hard enough (and when, too)) [In reply to]
On Tue, Aug 21, 2012 at 7:03 PM, Alex Gough <alex [at] earth> wrote:

>
> This also affects `when (Scalar)', which should
> require you to inform when() which of eq and == you really mean,
> as otherwise we're introducing heisenbugs.

I've lost track of how smart we're making things.

IIRC, when EXPR always does a comparison (\$_ ~~ EXPR), right?

Could it be made to vary depending on whether EXPR is simple or complex?
(Where "complex" possibly means, already has a comparison operator). E.g.

when (\$foo) { ... } # smartmatch
when (\$_ == \$foo) { ... } # explicit numeric match

I.e. could we avoid having to wrap it in an anonymous subroutine to get the
same effect?

-- David

damian at conway

Aug 21, 2012, 4:20 PM

Post #21 of 55 (211 views)
 Re: Newline legacy (Was: fixing smartmatch just hard enough (and when, too)) [In reply to]
David Golden wrote:

> I've lost track of how smart we're making things.

Less smart. More consistent. And without exceptions.

> IIRC, when EXPR always does a comparison (\$_ ~~ EXPR), right?

Not at present. But that's the intention with the change, yes.

> Could it be made to vary depending on whether EXPR is simple or complex?
> (Where "complex" possibly means, already has a comparison operator). E.g.

No. That's what we're specifically trying to get away from.

> I.e. could we avoid having to wrap it in an anonymous subroutine to get the
> same effect?

We do that now. It's widely considered to have been more of a problem than a
benefit.

Damian

damian at conway

Aug 21, 2012, 4:48 PM

Post #22 of 55 (211 views)
 Re: Newline legacy (Was: fixing smartmatch just hard enough (and when, too)) [In reply to]
Expanding just a little:

> when (\$_ == \$foo) { ... } # explicit numeric match
>
> I.e. could we avoid having to wrap it in an anonymous subroutine to get the
> same effect?

I have proposed that the syntax for this would be either:

when {\$_ == \$foo} { ... } # explicit numeric match

(which is no more onerous typographically than the current special case,
with the advantage of being semantically consistent with the rest of Perl,
which the current special case isn't) or else just:

when (0+\$foo) { ... } # explicit numeric match

(which is even less onerous).

Damian

damian at conway

Aug 21, 2012, 4:57 PM

Post #23 of 55 (211 views)
 Re: Newline legacy (Was: fixing smartmatch just hard enough (and when, too)) [In reply to]
Alex Gough wrote:

> In fact, using ~~ for
>
> Scalar ~~ Scalar
>
> should probably not be supported because it's inherently ambigious,
> and therefore dumb.

The plan is to make it inherently unambiguous, and therefore smart. :-)

> This also affects `when (Scalar)', which should
> require you to inform when() which of eq and == you really mean,

...which you can do under the various proposals, either by being explicit

when {\$_ == 0} {...}

# All these are numbers so always smartmatch via ==
when (0) {...}
when (\$num * 1) {...}
when (0+\$num) {...}
when (length \$str) {...}

# All these are strings so always smartmatch via eq
when ('0') {...}
when ("\$str") {...}
when (\$num . "") {...}
when (caller()) {...}

And, if Chip's "what-was-I-originally" plans bear fruit, even:

when (\$var) {...}

could eventually be unambiguous and predicatble: it could use the
appropriate comparator for the actual type of value that was originally
assigned to \$var.

Damian

perl.p5p at rjbs

Aug 21, 2012, 4:59 PM

Post #24 of 55 (211 views)
 Re: Newline legacy (Was: fixing smartmatch just hard enough (and when, too)) [In reply to]
* Jesse Luehrs <doy [at] tozt> [2012-08-21T09:21:32]
> On Tue, Aug 21, 2012 at 10:59:05AM +1000, Damian Conway wrote:
> >
> > Would that be a feasible solution?
>
> I think this is a much better solution than "looks like a number".

I thought so too, and I'm glad to see you on board, too, Jesse, because it is a
good omen for me not being out in left field.

I'm out of town right now, but I'm reading p5p and keeping this thread in mind.
I should post a thought-out follow up on Friday.

--
rjbs
Attachments: signature.asc (0.48 KB)

xdaveg at gmail

Aug 21, 2012, 5:13 PM

Post #25 of 55 (211 views)
 Re: Newline legacy (Was: fixing smartmatch just hard enough (and when, too)) [In reply to]
On Tue, Aug 21, 2012 at 7:48 PM, Damian Conway <damian [at] conway> wrote:

> I have proposed that the syntax for this would be either:
>
> when {\$_ == \$foo} { ... } # explicit numeric match
>

Right! I mentioned that before and like it.

-- David

 1 2 3  View All Index | Next | Previous | Print Thread | View Threaded

 Perl     porters