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

Re: Revisiting smart match

Thread Previous | Thread Next
From:
Father Chrysostomos
Date:
August 1, 2017 21:27
Subject:
Re: Revisiting smart match
Message ID:
20170801212707.26108.qmail@lists-nntp.develooper.com
Zefram wrote:
> So, my suggestion for the ruleset:
> 
>     0: RHS overloading
>     1: undef on the RHS: !defined($lhs)
>     2 (optional): plain string (defined, non-glob, non-regexp, non-ref
>        scalar) on the RHS: $lhs eq $rhs

I think we need item 2.  There will be too much grief without it.  I do
agree on making no distinction between numbers and strings.

>     3: anything else: croak "invalid smartmatcher"
> 
> The Regexp class should overload smartmatch to perform a regexp match.
> MooseX::Types metaobjects should overload smartmatch to perform a type
> membership test.

Alternatively, we could add &{} overloading to the Regexp package (which would be a useful thing regardless of smartmatch), so the list could be:

    0: RHS smartmatch overloading
    1: RHS is callable (&{} overloading or reftype eq 'CODE')
    2: undef
    3: string
    4: error

That is still mentally manageable.  I am not strongly attached to it.

> There's further complication about the when() construct, which is
> inconsistent in how it uses the result of evaluating the expression
> inside the parens.  Sometimes it treats the result as a truth value,
> directly governing whether to execute its block, and sometimes it treats
> the result as a smartmatcher, against which to implicitly match $_.
> The decision is based on the top-level operator of the expression.
> This is just confusing and should be ditched.  If you want smartmatching
> with no extra typing, change the parens: when() can treat the expression
> result as a truth value while when[] treats it as a smartmatcher.
> We could add if[] while we're at it.

This came up before.  The previous proposal was to keep smartmatch for
when(){}, and to disable it for when{}{} (with a true block for the
protasis).  I cannot say which is better.

The one issue that never got resolved before (and which ultimately
derailed the overhaul attempt) was how to deal with 'break' and
'continue' semantics.

'break' and 'continue' are actually inconsistent and buggy in the way
they are implemented.  Sometimes they will accept a 'for' loop and
sometimes they will not (I think; I do not remember the details).
'next' and 'last' ignore any 'given' block.

My proposal was to make 'break' and 'continue' into synonyms for 'last'
and 'next', respectively.  The then pumpking thought it still valuable
to make a distinction between them, but never made a proposal with
enough detail to implement.  So I asked, and waited....

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About