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

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

Thread Previous | Thread Next
Leon Timmermans
August 24, 2012 05:17
Re: fixing smartmatch just hard enough (and when, too)
Message ID:
On Fri, Aug 24, 2012 at 1:40 AM, Damian Conway <> wrote:
> Leon Timmermans wrote:
>> I suspect in practice junctions may be the only use-case for it. I
>> can't think of any other use-case.
> Interesting. I can think of numerous other use-cases...
>     1. In this very thread we've already seen Robert Sedlacek excellent
>        suggestion for type objects, for which I've already demonstrated
>        several possible ~~-overloadings.
>     2. I'd also very much like to be able to overload ~~ for
>        Regexp::Grammar objects.
>     3. And I can imagine that a similar overloading of ~~ for objects
>        encapsulating Marpa grammars would be of even greater value.
>     4. The bioinformatics people might well like to be able to overload
>        ~~ to perform searches or alignments on objects representing DNA
>        and RNA sequences.
>     5. I can also imagine ~~ overloaded to support Query objects:
>             if ($db ~~ $query) {...}
>     6. And I already have plans to allow InputConstraint objects, for
>        abstracting input filtering using my IO::Prompter module, by
>        being internally smartmatched:
>             my $input = prompt 'Enter a number', must=>$constraint_obj;
> In fact, in almost any circumstances where I want an API to offer client
> code some kind of inversion-of-control, it's likely that I'll want to
> clients to be able to pass an object or class encapsulating that
> control, which my code will then smart-match against.
> So I think there are, in fact, endless use-cases for overloaded
> smartmatching.

As doy already explained, I have an issue only with LHS. In fact I
wrote Smart::Match, I'm absolutely convinced that right handed
overloading is useful and sensible. It's left handed overloading that
seems problematic to me.

>> Why do you expect that to work with smart-match when it doesn't with
>> subroutine calls, or a dozen other things?
> Because then at least there will be *one* way to make it work
> correctly. :-)

I don't find that a convincing argument. That's 5.10 logic to me.
Getting it out now is not better than getting it right.

>> If ¬«is_prime(any(9,10,11))¬» is not equivalent to ¬«any(is_prime(9),
>> is_prime(10), is_prime(11))¬», it's not a junction in the first place.
>> It's just an abstraction that fakes it half of the time and leaks like
>> a sieve the other half. Supporting them in a few circumstances and not
>> in others seems silly and wrong to me.
> Well, I agree. But doing them full-arsed will require fundamental changes
> to Perl 5's subroutine and method dispatch semantics. And I don't believe
> that's being proposed...or even contemplated.

I can imagine a «use junctions» CPAN module that would enable it, it's
'just' a matter of rewriting ops. Though I'm not sure it would work
well with other Perl 5 features.

>> IMO doing them half-arsed is worse than not doing them at all.
> I would disagree. Better half-assed, than totally arse-less.

I think core should have higher standards than that; we shouldn't add
features that lightly.

> It's like OO. Until the advent of Moose, Perl's approach to OO has
> always been half-arsed. But better that half-arsed OO than to have had
> no Perl OO at all for the past two decades!

However, fact is that we can build Moose on top of our traditional OO.
It's unfriendly and cumbersome and a whole bunch of other adjectives,
but you can build something seemingly sensible and complete on top of
it (even if the insides are sometimes non-sensible). That is a trait
I'm missing in what you're proposing.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About