Mailing List Archive

On Jun 28, 2012, at 6:38 PM, Father Chrysostomos via RT wrote:
> On Thu Jun 28 09:17:43 2012, rs@474.at wrote:
>> On Thu, 2012-06-28 at 08:24 -0700, Father Chrysostomos via RT wrote:
>>> On Thu Jun 28 06:53:40 2012, dmcbride@cpan.org wrote:
>>>> Anyone coming from a C or shell background is going to be used to this
>>>> idea,
>>>> even if not exactly the same construct, and perl's lack of switch
>>>> statement
>>>> has long been a sticking point.
>>>
>>> We have always had for/last.
>>
>> Which can be quite confusing when it's used for non-looping.
>
> I’ve never had that problem. That use of for has been documented (in
> perlsyn I think) for a long time.

FWIW, I always use "foreach" for the looping case, and "for" for the non-looping case. It makes for some sort of sanity.



Liz

On Thu, Jun 28, 2012 at 6:17 PM, Robert Sedlacek <rs@474.at> wrote:
> On Thu, 2012-06-28 at 08:24 -0700, Father Chrysostomos via RT wrote:
>> On Thu Jun 28 06:53:40 2012, dmcbride@cpan.org wrote:
>> > Anyone coming from a C or shell background is going to be used to this
>> > idea,
>> > even if not exactly the same construct, and perl's lack of switch
>> > statement
>> > has long been a sticking point.
>>
>> We have always had for/last.
>
> Which can be quite confusing when it's used for non-looping.

I agree, it's ugly.

>> But there is also the icky scoping of when and break, and how they
>> interact when it comes to nested sub calls, some having for(), some
>> given(), etc.  Sometimes you get errors that are just wrong.
>>
>> Also, when’s algorithm for guessing when you want implicit smartmatch is
>> completely broken.  Even the examples in the docs of how it ‘usually
>> does what you want’ don’t work as expected and have bizarre results.
>
> Would the first part not be fixable by requiring 'when' to be inside
> 'given'? Since 'when' breaks out implicitly, it might be too hard to
> predict when it's interacting with unknowns. If it always belongs to a
> 'given' that would work out fine, right?

That would completely break my uses of it. I'm not interested in a
when that does that.

> I can't really comment on the smartmatch detection issues, since I'm not
> really up-to-date on them. Is it a problem of specification or
> implementation? I assume this behavior is only needed so one can have
> auto-breaking conditions that aren't smatch-matches on the same level as
> the smart-matching cnoditions? Maybe there is a way to distinguish these
> two cases better? Or just always use smart-matching and let CPAN provide
> a way to side-step it.

It's awful. In Smart::Match, I actually had to overload not just
smartmatching, but also boolean conversion to do smartmatch, because
depending on the function having arguments or not it can trigger
boolean instead of smartmatching behavior. It required an XS hack to
get the lexical $_ right :-(.

> How about instead of deprecating it, the undesirable features of it are
> deprecated and the rest is left to CPAN? The Smart::Match modules is
> actually quite nice and makes for some readable code. A generic,
> overloadable comparison operator that isn't (semantically) related to
> either string or numerical comparison seems quite useful.

I agree.

Leon

On 06/28/2012 03:19 AM, Father Chrysostomos via RT wrote:
> Steffen Müller, could you run a smoke against sprout/givendefsv?

Running. Look for progress at

http://users.perl5.git.perl.org/~tsee/progress.html

and for output at

http://users.perl5.git.perl.org/~tsee/givendefsv/
and
http://users.perl5.git.perl.org/~tsee/givendefsv_withmissing_dists/

--Steffen

On 6/28/2012 9:49 AM, Jesse Luehrs wrote:
> On Thu, Jun 28, 2012 at 09:38:45AM -0700, Father Chrysostomos via RT wrote:
>>> How about instead of deprecating it, the undesirable features of it are
>>> deprecated and the rest is left to CPAN? The Smart::Match modules is
>>> actually quite nice and makes for some readable code. A generic,
>>> overloadable comparison operator that isn't (semantically) related to
>>> either string or numerical comparison seems quite useful.
>> So it’s a generic ‘do something funny with this object’ operator? Do
>> you mean the rhs has to be an object with smartmatch overloading, and
>> everything else is deprecated?
> That is pretty close to what rjbs proposed last year.

Once my magic flags patch is accepted, we can make string and number and
boolean smart matching REALLY WORK. So let's not throw the baby out
with the bathwater, at least until we verify that isn't a real baby.

On Thu Jun 28 23:03:02 2012, smueller@cpan.org wrote:
> On 06/28/2012 03:19 AM, Father Chrysostomos via RT wrote:
> > Steffen M�ller, could you run a smoke against sprout/givendefsv?
>
> Running. Look for progress at
>
> http://users.perl5.git.perl.org/~tsee/progress.html
>
> and for output at
>
> http://users.perl5.git.perl.org/~tsee/givendefsv/
> and
> http://users.perl5.git.perl.org/~tsee/givendefsv_withmissing_dists/

Thank you.

The only new failures are due to timing or network issues.

I think we can safely make given alias $_ the way for does.

--

Father Chrysostomos


---
via perlbug: queue: perl5 status: resolved
https://rt.perl.org:443/rt3/Ticket/Display.html?id=113818

* Reverend Chip <rev.chip@gmail.com> [2012-06-30 01:50]:
> On 6/28/2012 9:49 AM, Jesse Luehrs wrote:
> > On Thu, Jun 28, 2012 at 09:38:45AM -0700, Father Chrysostomos via RT wrote:
> >>> How about instead of deprecating it, the undesirable features of
> >>> it are deprecated and the rest is left to CPAN? The Smart::Match
> >>> modules is actually quite nice and makes for some readable code.
> >>> A generic, overloadable comparison operator that isn't
> >>> (semantically) related to either string or numerical comparison
> >>> seems quite useful.
> >> So it’s a generic ‘do something funny with this object’ operator?
> >> Do you mean the rhs has to be an object with smartmatch
> >> overloading, and everything else is deprecated?
> > That is pretty close to what rjbs proposed last year.
>
> Once my magic flags patch is accepted, we can make string and number
> and boolean smart matching REALLY WORK. So let's not throw the baby
> out with the bathwater, at least until we verify that isn't a real
> baby.

No, not in fact. It makes it almost certain to work for values that came
from the source code but all data coming in from I/O, number or not,
will be marked as a string, and explicit care will have to be taken to
type-coerce it to a number or boolean even under your patch. Admittedly
the patch will make it possible to do that at all. But the fundamental
nature of Perl 5 as a language with polymorphic values (which therefore
needs to have monomorphic operators) will not change, and smartmatch as
a polymorphic operator by design cannot suddenly cease being inherently
in opposition to that nature.

It will work much better, but it cannot work right.

(It may not need to work right if it is close enough. I am sceptical and
will be quite unsurprised if it turns out to have to, but my mind is not
made up.)

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

On Wed, Jul 11, 2012 at 07:27:35AM +0200, Aristotle Pagaltzis wrote:
> Reverend Chip <rev.chip@gmail.com> [2012-06-30 01:50]:
> > Once my magic flags patch is accepted, we can make string and number
> > and boolean smart matching REALLY WORK. So let's not throw the baby
> > out with the bathwater, at least until we verify that isn't a real
> > baby.
>
> No, not in fact. It makes it almost certain to work for values that came
> from the source code but all data coming in from I/O, number or not,
> will be marked as a string, and explicit care will have to be taken to
> type-coerce it to a number or boolean even under your patch.

Well, that's a fair cop. I wonder, though...

WARNING - WILD ASS GUESSING AHEAD

... if my patch's ability to correctly discern the RIGHT operand type might
save things. What if, e.g.

$a ~~ 42

would be true if $a="42", while being false and not warning if $a="foo"?
(Using looks_like_number() as a fallback, you see.) This whole approach
only becomes practical once we can be sure that the 42 is really 42, which
is where my patch helps.
--
Chip Salzenberg

* Rev. Chip <rev.chip@gmail.com> [2012-07-11 09:35]:
> What if, e.g.
>
> $a ~~ 42
>
> would be true if $a="42", while being false and not warning if
> $a="foo"? (Using looks_like_number() as a fallback, you see.) This
> whole approach only becomes practical once we can be sure that the 42
> is really 42, which is where my patch helps.

Part of me is feeling queasy; part of me is thinking this might just
work. I don’t think I will know which is the right intuition before
I can give it a try in anger.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

On Wed, Jul 11, 2012 at 2:29 AM, Rev. Chip <rev.chip@gmail.com> wrote:
> On Wed, Jul 11, 2012 at 07:27:35AM +0200, Aristotle Pagaltzis wrote:
>> Reverend Chip <rev.chip@gmail.com> [2012-06-30 01:50]:
>> > Once my magic flags patch is accepted, we can make string and number
>> > and boolean smart matching REALLY WORK. So let's not throw the baby
>> > out with the bathwater, at least until we verify that isn't a real
>> > baby.
>>
>> No, not in fact. It makes it almost certain to work for values that came
>> from the source code but all data coming in from I/O, number or not,
>> will be marked as a string, and explicit care will have to be taken to
>> type-coerce it to a number or boolean even under your patch.
>
> Well, that's a fair cop. I wonder, though...
>
> WARNING - WILD ASS GUESSING AHEAD
>
> ... if my patch's ability to correctly discern the RIGHT operand type might
> save things. What if, e.g.
>
> $a ~~ 42
>
> would be true if $a="42", while being false and not warning if $a="foo"?
> (Using looks_like_number() as a fallback, you see.) This whole approach
> only becomes practical once we can be sure that the 42 is really 42, which
> is where my patch helps.
> --
> Chip Salzenberg

Am I right to assume that

perl -E'$a = 42; $b = "$a text"; say $b ~~ $a ? 1 : 0'
perl -E'$a = "42"; $b = "$a text"; say $b ~~ $a ? 1 : 0'
perl -E'$a = 42; $b = "$a text"; $c = 0+$b; say $b ~~ $a ? 1 : 0'
# <- this one is pointless
perl -E'$a = "42"; $b = "$a text"; $c = 0+$a; say $b ~~ $a ? 1 : 0'

will print out:

1
0
1
0

instead of:

1
0
1
1

as it does now

On 7/11/2012 8:33 AM, Brad Gilbert wrote:
> On Wed, Jul 11, 2012 at 2:29 AM, Rev. Chip <rev.chip@gmail.com> wrote:
>> On Wed, Jul 11, 2012 at 07:27:35AM +0200, Aristotle Pagaltzis wrote:
>>> Reverend Chip <rev.chip@gmail.com> [2012-06-30 01:50]:
>>>> Once my magic flags patch is accepted, we can make string and number
>>>> and boolean smart matching REALLY WORK. So let's not throw the baby
>>>> out with the bathwater, at least until we verify that isn't a real
>>>> baby.
>>> No, not in fact. It makes it almost certain to work for values that came
>>> from the source code but all data coming in from I/O, number or not,
>>> will be marked as a string, and explicit care will have to be taken to
>>> type-coerce it to a number or boolean even under your patch.
>> Well, that's a fair cop. I wonder, though...
>>
>> WARNING - WILD ASS GUESSING AHEAD
>>
>> ... if my patch's ability to correctly discern the RIGHT operand type might
>> save things. What if, e.g.
>>
>> $a ~~ 42
>>
>> would be true if $a="42", while being false and not warning if $a="foo"?
>> (Using looks_like_number() as a fallback, you see.) This whole approach
>> only becomes practical once we can be sure that the 42 is really 42, which
>> is where my patch helps.
>> --
>> Chip Salzenberg
> Am I right to assume that
>
> perl -E'$a = 42; $b = "$a text"; say $b ~~ $a ? 1 : 0'
> perl -E'$a = "42"; $b = "$a text"; say $b ~~ $a ? 1 : 0'
> perl -E'$a = 42; $b = "$a text"; $c = 0+$b; say $b ~~ $a ? 1 : 0'
> # <- this one is pointless
> perl -E'$a = "42"; $b = "$a text"; $c = 0+$a; say $b ~~ $a ? 1 : 0'
>
> will print out:
>
> 1
> 0
> 1
> 0
>
> instead of:
>
> 1
> 0
> 1
> 1
>
> as it does now

In short, yes.
The first example breaks down to "42 text" ~~ 42. I am not sure but I
think this should succeed as it does.
(Whether it warns is a separate question. I think it should. I think.)
The second example is two different strings, so it fails as it should.
The third and fourth examples just add doing math on a string, and the
point of my scalar types patch is to ensure that has (almost) no visible
effects.

On Fri Jun 29 16:46:56 2012, rev.chip@gmail.com wrote:
> On 6/28/2012 9:49 AM, Jesse Luehrs wrote:
> > On Thu, Jun 28, 2012 at 09:38:45AM -0700, Father Chrysostomos via RT
> wrote:
> >>> How about instead of deprecating it, the undesirable features of
> it are
> >>> deprecated and the rest is left to CPAN? The Smart::Match modules
> is
> >>> actually quite nice and makes for some readable code. A generic,
> >>> overloadable comparison operator that isn't (semantically) related
> to
> >>> either string or numerical comparison seems quite useful.
> >> So it’s a generic ‘do something funny with this object’ operator?
> Do
> >> you mean the rhs has to be an object with smartmatch overloading,
> and
> >> everything else is deprecated?
> > That is pretty close to what rjbs proposed last year.
>
> Once my magic flags patch is accepted, we can make string and number
> and
> boolean smart matching REALLY WORK. So let's not throw the baby out
> with the bathwater, at least until we verify that isn't a real baby.

Which part of the baby? Your patch, if I remember, exposed the
stringiness or numericity as an API, which I think is a bad idea; not
for technical reasons, but because it is too much of a cultural shift.
Have you ever written a bridge between two programming languages, one of
which is Perl? I have. Overloaded objects proved extremely useful.
But then I found myself having to apply workarounds all over the place
for code that does different things based on whether an argument is a
reference. If we start allowing code to say if(is_string($arg)){...}
then this will open up a can of worms. We will just end up with more
CPAN modules that don’t ‘do things right’, partly because ‘right’ has
been redefined in some peoples’ minds. String overloading will become
even less usable. There is also the problem that all dumping modules
will become officially buggy overnight.

Traditionally Perl has had typed operators and (mostly) typeless values,
the few warts notwithstanding. And I believe those warts really are
warts. I have been working on fixing those that I can over time. I
think if we design any new interfaces that treat 3 and "3" differently,
or codify any existing interfaces that do so, we will be taking a step
in the wrong direction.

--

Father Chrysostomos


---
via perlbug: queue: perl5 status: resolved
https://rt.perl.org:443/rt3/Ticket/Display.html?id=113818

On Wed, Jul 11, 2012 at 12:38:41PM -0700, Father Chrysostomos via RT wrote:
> Which part of the baby? Your patch, if I remember, exposed the
> stringiness or numericity as an API [...]

Yes, insofar as conversions no longer lose track of the original type.

> which I think is a bad idea; not for technical reasons, but because it is
> too much of a cultural shift.

Can't agree. Culture is subjective and interactive; we both form it and are
formed by it. And we interact with the outside world, some of which has
very strong opinions on strings vs. numbers. Ever ask Larry if he wishes
he'd made a boolean type? I think he would, and we'd all be better off.

> If we start allowing code to say if(is_string($arg)){...} then this will
> open up a can of worms. We will just end up with more CPAN modules that
> don’t ‘do things right’, partly because ‘right’ has been redefined in some
> peoples’ minds.

I can't undererstand this argument. It's not that I disagree with it, I
don't understand what the argument *is*. Could you please be more specific?
Beware of being persuasive with a slippery slope argument, too.

> There is also the problem that all dumping modules will become officially
> buggy overnight.

Now I know you're missing the point. Dumping modules already distinguish
numbers from strings.
--
Chip Salzenberg

* Rev. Chip <rev.chip@gmail.com> [2012-07-12 00:35]:
> On Wed, Jul 11, 2012 at 12:38:41PM -0700, Father Chrysostomos via RT wrote:
> > Which part of the baby? Your patch, if I remember, exposed the
> > stringiness or numericity as an API [...]
>
> Yes, insofar as conversions no longer lose track of the original type.
>
> > which I think is a bad idea; not for technical reasons, but because
> > it is too much of a cultural shift.
>
> Can't agree. Culture is subjective and interactive; we both form it
> and are formed by it. And we interact with the outside world, some of
> which has very strong opinions on strings vs. numbers. Ever ask Larry
> if he wishes he'd made a boolean type? I think he would, and we'd all
> be better off.

This is a nonsensical statement. If it were true on the face of it then
the smartmatch operator would not be causing the problems that it does.
The problem is that a language is a whole. You cannot change parts of to
work in ways that do not harmonise with other parts and expect the whole
to continue to fit together equally well. A successful ”cultural shift”
of the sort you postulate would in truth require razing most of the
language and doing over the entire design starting from key decisions
about the data model. (I believe if you did a good job with it based on
the premises implied, you would be led to a design much alike Python in
its data model and set of operators. That is not a bad thing per se but
I would have less interest in the result than I do in Perl as she is.)

> > If we start allowing code to say if(is_string($arg)){...} then this
> > will open up a can of worms. We will just end up with more CPAN
> > modules that don’t ‘do things right’, partly because ‘right’ has
> > been redefined in some peoples’ minds.

Two responses, FC:

1. In most cases such code will be as buggy as code that tries to look
at the UTF8 flag now. I believe the response should then be the same
as it is now to people who write code that looks at the UTF8 flag:
“stop that”.

2. It does not make a good argument against the patch because people
*already* try to write such code with such as `looks_like_number`;
this patch would at least allow such code to work better in those
cases where that is motivated by a legitimate desire, of which cases
there are a few (most prominently to my mind, JSON de-/serialisers).

Ultimately I believe Chip’s patch really makes no serious difference to
the language, but will alleviates some of the pain when having to do
things in Perl that cut against its grain to some extent. That seems
desirable.

> I can't undererstand this argument. It's not that I disagree with it,
> I don't understand what the argument *is*. Could you please be more
> specific? Beware of being persuasive with a slippery slope argument,
> too.

I think the issue with his argument is that you overestimate the impact
of your patch on the semantics of the language, or at least you present
it in language that so overestimates it. And after unwittingly following
you into that ditch, FC is noticing and complaining that down there is
not a good place to be. In a manner of speaking the slope is yours and
the slip is his. :-)

> > There is also the problem that all dumping modules will become
> > officially buggy overnight.
>
> Now I know you're missing the point. Dumping modules already
> distinguish numbers from strings.

And the reason it isn’t causing problems is that no one is relying on
that distinction in any deep way, as well they still shouldn’t even once
your patch is in place. He who starts to will find that problems follow.

Essentially your patch, to me, boils down to more reliable serialisation
for formats with a data model pickier than Perl’s, as well as fewer bugs
in the bitwise operators (which really means those operators should be
redesigned and the old design removed with prejudice; unfortunately that
is a lot less realistic than it is for smartmatch), and suchlike polish.

Therefore I like it.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

On Thu, Jul 12, 2012 at 11:35:42AM +0200, Aristotle Pagaltzis wrote:
> Ultimately I believe Chip’s patch really makes no serious difference to
> the language, but will alleviates some of the pain when having to do
> things in Perl that cut against its grain to some extent. That seems
> desirable.

That's fair. I like Perl's pre-smartmatch operators fine. I only intend to
reduce the pain of coping with the boundary between Perl's historical
contextual typing (where operator context controls, and data follows by
conversion) and intrinsic typing (where types are inherent to data, and
operators follow along). That boundary already lay inside the borders of
Perl due to the bitwise operators.

Smart match is a separate issue. If people want smart match they'll have
it, whether or not original types can be reliably found (which is all my
patch offers). If they don't want it, the patch won't change that either.

> > Beware of being persuasive with a slippery slope argument, too.
>
> I think the issue with his argument is that you overestimate the impact
> of your patch on the semantics of the language, or at least you present
> it in language that so overestimates it. And after unwittingly following
> you into that ditch, FC is noticing and complaining that down there is
> not a good place to be. In a manner of speaking the slope is yours and
> the slip is his. :-)

You're making more sense than I was. So: OK. Father C: ^^
--
Chip Salzenberg

On Thu Jul 12 02:36:51 2012, aristotle wrote:
> * Rev. Chip <rev.chip@gmail.com> [2012-07-12 00:35]:
> > On Wed, Jul 11, 2012 at 12:38:41PM -0700, Father Chrysostomos via RT
> wrote:
> > > If we start allowing code to say if(is_string($arg)){...} then
> this
> > > will open up a can of worms. We will just end up with more CPAN
> > > modules that don’t ‘do things right’, partly because ‘right’ has
> > > been redefined in some peoples’ minds.
>
> Two responses, FC:
>
> 1. In most cases such code will be as buggy as code that tries to look
> at the UTF8 flag now.

That’s exactly what I’m afraid of.

> I believe the response should then be the
> same
> as it is now to people who write code that looks at the UTF8 flag:
> “stop that”.

But that will be hard to back in the face of this ‘new feature’.

> 2. It does not make a good argument against the patch because people
> *already* try to write such code with such as `looks_like_number`;

Actually, there is nothing wrong with looks_like_number, as code using
it will treat 3 and "3" the same way. In fact, Perl’s unary negation
uses it. Any string beginning with [a-zA-Z], or any string that begins
with '-' and !looks_like_number gets string negation. Anything else
gets numeric negation. (Or at least that’s how it is in bleadperl, now
that I’ve fixed the inconsistencies.)

> this patch would at least allow such code to work better in those
> cases where that is motivated by a legitimate desire,

I still think looks_like_number is a better approach in most cases.

> of which
> cases
> there are a few (most prominently to my mind, JSON de-
> /serialisers).
>
> Ultimately I believe Chip’s patch really makes no serious difference
> to
> the language, but will alleviates some of the pain when having to do
> things in Perl that cut against its grain to some extent. That seems
> desirable.
>
> > I can't undererstand this argument. It's not that I disagree with
> it,
> > I don't understand what the argument *is*. Could you please be more
> > specific? Beware of being persuasive with a slippery slope argument,
> > too.
>
> I think the issue with his argument is that you overestimate the
> impact
> of your patch on the semantics of the language, or at least you
> present
> it in language that so overestimates it. And after unwittingly
> following
> you into that ditch, FC is noticing and complaining that down there is
> not a good place to be. In a manner of speaking the slope is yours and
> the slip is his. :-)
>
> > > There is also the problem that all dumping modules will become
> > > officially buggy overnight.
> >
> > Now I know you're missing the point. Dumping modules already
> > distinguish numbers from strings.
>
> And the reason it isn’t causing problems is that no one is relying on
> that distinction in any deep way, as well they still shouldn’t even
> once
> your patch is in place. He who starts to will find that problems
> follow.
>
> Essentially your patch, to me, boils down to more reliable
> serialisation
> for formats with a data model pickier than Perl’s,

If that is the reason for it, then I am not opposed, as long as the
documentation for the API makes it clear that using it to treat
arguments to functions differently is not its intended use and goes
against the spirit of everything Perl 5 stands for.

Let’s not have a repeat of the Unicode bug.

> as well as fewer
> bugs
> in the bitwise operators (which really means those operators should be
> redesigned and the old design removed with prejudice; unfortunately
> that
> is a lot less realistic than it is for smartmatch),

Not at all. Perl 6 has +| and +&, so why can’t Perl 5? Probably
because +~ already means something, right? ~| is how Perl 6 does
stringwise bitwise or. But ~ never means string in Perl 5, so we would
have to come up with something else. Maybe a feature feature could make
| ^ stringwise.

> and suchlike
> polish.
>
> Therefore I like it.
>
> Regards,


--

Father Chrysostomos


---
via perlbug: queue: perl5 status: resolved
https://rt.perl.org:443/rt3/Ticket/Display.html?id=113818

On Fri, Jul 13, 2012 at 12:15:17AM -0700, Father Chrysostomos via RT wrote:
> On Thu Jul 12 02:36:51 2012, aristotle wrote:
> > as well as fewer bugs in the bitwise operators (which really means those
> > operators should be redesigned and the old design removed with
> > prejudice; unfortunately that is a lot less realistic than it is for
> > smartmatch),
>
> Not at all.

Sadly, yes, some errors^Wodd design decisions are beyond fixing. Say, the
choice of $a[0] vs. @a[0] for example. I think it's clear that how | & ^
work, fundamentally, is stuck. All we can do is make them marginally less
astonishing.
--
Chip Salzenberg

* Father Chrysostomos via RT <perlbug-followup@perl.org> [2012-07-13 09:20]:
> On Thu Jul 12 02:36:51 2012, aristotle wrote:
> > * Rev. Chip <rev.chip@gmail.com> [2012-07-12 00:35]:
> > > On Wed, Jul 11, 2012 at 12:38:41PM -0700, Father Chrysostomos via RT wrote:
> > > > If we start allowing code to say if(is_string($arg)){...} then
> > > > this will open up a can of worms. We will just end up with more
> > > > CPAN modules that don’t ‘do things right’, partly because
> > > > ‘right’ has been redefined in some peoples’ minds.
> >
> > Two responses, FC:
> >
> > 1. In most cases such code will be as buggy as code that tries to look
> > at the UTF8 flag now.
>
> That’s exactly what I’m afraid of.
>
> > I believe the response should then be the same as it is now to
> > people who write code that looks at the UTF8 flag: “stop that”.
>
> But that will be hard to back in the face of this ‘new feature’.

I don’t really think so. A big part of the problem with the UTF-8 flag
was both the name (should’ve been used UOK) and that it was exposed
through “userspace” APIs that easily lead people to trying to rely on
it, as well as documentation that advertised it that way along with lots
of code in the core that exhibited the buggy behaviour.

That people would do the wrong thing in the face of such overwhelming
instruction to do that is no surprise.

There is no need for the magicflags patch to repeat these mistakes. It
need not come with an `is_string` function. If it even did it should be
called `has_pvok` or some such, and any docs should be clear on the
limits. But again, I don’t see a need to supply any API for this. You
get strings from string operators and numbers from numeric operators and
the rest is on a need to know basis, which mostly means XS is involved.

Some people will do the wrong thing regardless. You cannot help that.

> > 2. It does not make a good argument against the patch because people
> > *already* try to write such code with such as `looks_like_number`;
>
> Actually, there is nothing wrong with looks_like_number, as code using
> it will treat 3 and "3" the same way. In fact, Perl’s unary negation
> uses it. Any string beginning with [a-zA-Z], or any string that begins
> with '-' and !looks_like_number gets string negation. Anything else
> gets numeric negation. (Or at least that’s how it is in bleadperl, now
> that I’ve fixed the inconsistencies.)

Well… it depends, on what it’s trying to do. If you’re trying to write
a JSON serializer using looks_like_number the result will be broken. It
will produce number values in cases where it should spit out string
values, and, rarely, vice versa, with no good way of controlling it. So
you need some other signalling mechanism for this.

There are other cases… I know I had code that I couldn’t make work well
in some other circumstance, where looks_like_number was only the nearest
best thing to do. I wish I could remember what exactly it was.

With Chip’s patch this problem would go away.

> > this patch would at least allow such code to work better in those
> > cases where that is motivated by a legitimate desire,
>
> I still think looks_like_number is a better approach in most cases.

Yes well, as I said, depending on what you are doing.

> > Essentially your patch, to me, boils down to more reliable
> > serialisation for formats with a data model pickier than Perl’s,
>
> If that is the reason for it, then I am not opposed, as long as the
> documentation for the API makes it clear that using it to treat
> arguments to functions differently is not its intended use and goes
> against the spirit of everything Perl 5 stands for.
>
> Let’s not have a repeat of the Unicode bug.

Absolutely. See above.

> > as well as fewer bugs in the bitwise operators (which really means
> > those operators should be redesigned and the old design removed with
> > prejudice; unfortunately that is a lot less realistic than it is for
> > smartmatch),
>
> Not at all. Perl 6 has +| and +&, so why can’t Perl 5? Probably
> because +~ already means something, right? ~| is how Perl 6 does
> stringwise bitwise or. But ~ never means string in Perl 5, so we
> would have to come up with something else. Maybe a feature feature
> could make | ^ stringwise.

Hmm.

Hmm.

The idea that this could be fixable is more than a little tempting…

Do you think we could also eventually untangle C<x> from C<x()> the way
that Perl 6 has? :-)

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

On Fri, Jul 13, 2012 at 11:27:32AM +0200, Aristotle Pagaltzis wrote:
> There is no need for the magicflags patch to repeat these [utf8]
> mistakes. It need not come with an `is_string` function.

I was *just* thinking the same thing this morning. It all depends on what
the meaning of "is" is, as a famous lawyer once said. The predicate "is a
string" is NOT what the patch offers, so a test named "isstring" is wrong.

My current best choice is "created_as_string", "created_as_integer",
"created_as_number", "created_as_boolean". And perhaps "created_as"
returning 'INT', 'NUM', 'STR', 'BOOL', and possibly other values depending
on what's handy. These names tell the truth, as all we can reveal is the
way a value was created, not what it _is_ in any existential sense.

We can bikeshed the name, but the principle seems right to me.

(I expect these would go in Scalar::Util.)

> If you’re trying to write a JSON serializer using looks_like_number the
> result will be broken.

Exactly so.
--
Chip Salzenberg