in reply to Re^13: Use of uninitialized value in substr
in thread Use of uninitialized value in substr

And like I said The real question is about making explicit undef semantically different from indirect undef; and therefore making it more powerful, and useful.. It was not about what is, but what could be.

Like I said back here

But it's no big deal. (Really, it isn't).

But what follows that is the crux.

Is substr $x, $start, $end, undef more indicative of deleting the substring than substr $x, $start, $end, '';?

Three extra characters for sure, and I'm rarely in favour of longer over shorter, but in this case I think yes. The consensus appears to be no.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
RIP an inspiration; A true Folk's Guy

Replies are listed 'Best First'.
Re^15: Use of uninitialized value in substr
by ikegami (Patriarch) on May 04, 2010 at 02:09 UTC

    Is substr $x, $start, $end, undef more indicative

    Not for me (concatenating undef?), but that's definitely subjective. I understand the rationale.

    But it's no big deal. (Really, it isn't).

    I think it is, because it creates so many questions with no answers. Why does passing undef to substr sometimes give a warning, and sometimes it doesn't? How come lc(undef) gives a warning? How can I pass this special new undef using a variable? etc. Yes, they can be explained, but there shouldn't be a need to.

    A solution shouldn't create a host of new problems. Yes, they are small problems, but the gain is even smaller.

[reply]
[d/l]
      How come lc(undef) gives a warning?
      I know, I know! It's because you're using 5.12! (lc(undef) doesn't give a warning in 5.10, 5.8.x or 5.6.x).
[reply]
[d/l]

        hehe, good one. (Just to be clear, I meant as opposed to the silence from substr(..., undef).)

        Thanks for the heads up on utime, too. I don't get it, though.

[reply]
[d/l]
[select]
      (concatenating undef?)

      Deletion of a substring might be implemented as the concatenation of two strings, created from the substrings either side of the deleted portion. It might be implemented as the copying over the deleted portion by the residual, combined with the reduction of CUR. But it doesn't matter which. The concept of deleting a substring in-place is what is important. And the four-arg substr ecapsulates that.

      And the notion was that replacement with undef more clearly denotes that, than replacement with a null length string constant.

      But it's no big deal. (Really, it isn't)...

      I think it is,.

      Review the context of that quote. You cannot decide if something is a big deal to me. No big deal, because I wasn't proposing a change. Just discussing the possibilty.

      For the most part, it isn't a "special new undef", just a recognition and use of an existing implementation detail.

      It was just a notion, worthy of discussion. But not worthy of all this. You've put far more effort into trying to find problems with it, than I have in support of it. And that's the real problem here. Instead of discussing the idea, you've rushed headlong into trying prove it is impossible to implement.

      There are already plenty of non-orthogonal concepts in Perl--implemented that way because they make something easier or clearer or more intuitive--despite that they raise questions from newbies regarding their lack of orthogonality. We forgive Perl those non-orthogonalities, because they make Perl so practical.

      Whether it is feasible or practical in Perl 5, or might confuse newbies, is essentially irrelevant. If it was judged useful, it could be implemented. But you first have to decide if its useful. And I don't think that your say or nay (nor mine), is the deciding factor in that.

      I think--and I believe that there is CS wisdom to back this up--that the concept explicitbottom being distinguishable from an uninitialised variable, and the ability to make decisions based upon that distinction, is a useful one. Maybe--should anyone else see the merit in it--it isn't too late to incorporate that into Perl 6. But I'm not proposing that either. I just wanted to discuss the notion.

      But (once again), your knee-jerk reaction, persistent misunderstanding, and rapid fire careering off in all directions, mean that the little relevant discussion that has taken place, has been diluted to near homeopathic proportions.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Seekers of Perl Wisdom