raiph_mellor
Sep 3, 2018 · 3 min read

It’s a bug on RT at https://rt.perl.org/Ticket/Display.html?id=130959

And on GH too: https://github.com/rakudo/rakudo/issues/2238

The way I see it the smart in smart match is a flavor of DWIM. DWIMs come with WATs. (cf https://www.reddit.com/r/perl6/comments/8s2vl8/_/e12tf1r/) WATs are positive things even though folk have a tendency to see them as negatives.

WATs teach us, or remind us, of something useful. That’s essentially the spirit of many of your blog posts; it’s a wise perspective.

Sometimes WATs lead us to gratefully individually and/or communally adjust our mental models to accommodate more powerful ways of looking at things. These WATs are essentially just teachers that come for free with the DWIM.

Other times we individually and/or communally feel we don’t get enough back to make the trade worthwhile. We still have to alter our mental models in this latter case, but in this latter scenario it’s to accommodate an unfortunate reality. We may drop the language, lobby to change it and/or write a PR to fix it, avoid features that can repeat the WAT, or just remember it as an oddity to watch out for.

What you describe in your post is a WAT. So what does this WAT teach us or remind us? Is the tradeoff it represents, relative to the DWIM, worthwhile? Is there a better tradeoff? Would it be worth switching to it?

Your WAT taught me that range smart match doesn’t mirror range iteration when the endpoints are strings. It reminded me that P6 is very DWIMy and that its approach to language versions, types, and multiple dispatch, makes it easy to rationally evolve over time many of its DWIMs to reduce exposure to WATs that are communally deemed unacceptable.

And that led me to look and see that there are RT and GH issues related to this WAT. It appears to me to be the result of an unfortunate oversight or lack of tuits rather than a deliberate decision. Though the GH has been given an @Larry tag. So that teaches me we’re at least recording and thinking about these things. Kudos to Zoffix and Liz. Also to Alex for adding a 6.e label, although…

I currently think the default smart match of a range with string endpoints should mirror its default iteration strategy. If @Larry agrees, I would love to see someone fix it for 6.d. If such a fix went through to completion of the process it would presumably involve:

  • writing up the rationale for the change and seeking feedback (this post);
  • adding it to the proposed list of changes for 6.d (a file in the perl6 repo at GH);
  • copying a roast test that I assume exists for iteration of a range with string endpoints to a new one for smart match against the same range (or to replace whatever is there now if there’s consensus this spec change is worthwhile);
  • writing the P6 code to make the test pass (presumably code that’s similar to the code written to iterate);
  • merging this with v6.d.PREVIEW;
  • running the ecosystem toaster to see what the semantics fallout is; running something similar to see what the performance fallout is;
  • making the decision to go ahead with the change and writing notes about it or culling and reverting it.

From a technical complexity perspective I think you or I could realistically take this on and get it changed in 6.d.

I know I won’t because I’ve got a huge backlog of other things I need to do first. So that reminds me to be patient with myself and everyone else. And that reminds me that one of the three Perl programmer virtues is impatience. And that reminds me I’m perhaps not as virtuous as Perl’s BDFL urges me to be. :)

    raiph_mellor

    Written by

    Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
    Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
    Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade