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

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

Thread Previous | Thread Next
Damian Conway
August 23, 2012 16:41
Re: fixing smartmatch just hard enough (and when, too)
Message ID:
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

> 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. :-)

> 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.

> IMO doing them half-arsed is worse than not doing them at all.

I would disagree. Better half-assed, than totally arse-less.

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!

Of course, I'd much prefer fully integrated junctions throughout the
Perl 5 core. But, given that's extremely unlikely, then I'd still prefer
half-arsed junctions in the core, with the possibility (e.g. via
overloaded smartmatching) to maybe three-quarter-arse them.

>> If CodeRef testing comes first, I'm screwed.
> No you're not. If you solve the problem at the other end, it's
> possible to write a solution that would actually work.

Sure, but *I* can't write that solution (in Perl).
The core-elves would have to solve it.

And solving junctions was just one example. When the next new idea--
type objects, or grammar objects, or DNA alignment objects, or query
objects or constraint objects--needs to be implemented (or even just
prototyped as a class), we're going to need to overload smartmatching
on that too.

> That will require an approach that is much less superficial than what
> you're approaching here though, sadly.

I agree.

But since that is probably not going to happen for junctions, and even
more probably not going to happen for the other half-dozen sample
use-cases that I enumerated above, then I'd rather have a superficial
solution than no solution at all.


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