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

Re: Revisiting smart match

Thread Previous | Thread Next
From:
Father Chrysostomos
Date:
November 28, 2017 05:59
Subject:
Re: Revisiting smart match
Message ID:
20171128055952.1569.qmail@lists-nntp.develooper.com
Zefram wrote:
> Father Chrysostomos wrote:
> >If we can make 'break' equivalent to 'next', then I will likely use
> >'when' frequently.
> 
> Are you referring purely to the "break" keyword here, or also to the
> implicit jump at the end of a "when" block?  I'm guessing the latter,

I actually meant both, but it would not have to be that way.

> and that you'd mostly not have explicit "break"s, but you're saying
> you'd use "when" in types of loop other than "foreach".

Of course:

    while (<>) {
        when (this) { ... }
        when (that) { ... }
    }

> 
> Making the implicit jump a "next" seems sensible.  I'm dubious about
> having a "break" keyword as a synonym of "next", because it would increase
> the confusion that arises when comparing the loop control keywords to C.
> C's "break" is (when applied to loops) our "last", so to have a "break"
> that behaves like C's "continue" seems like it's asking for trouble.
> How would you feel about having no "break" keyword at all, and just using
> "next" or "last" to get out of a "given"?

That would be fine.  I don't know.  Do we need to break code already
using break?

> OK.  I suggest "having" for smartmatch and "being" for condition.
> They show some thematic relationship to each other, and "being" is
> stylistically quite distinct from "if" (whereas "when" is nearly a
> synonym for "if", and brings in misleading temporal connotations).
> So the earlier example would be
> 
>     given ($input) {
>         being ($_ eq "string") { die "A" }
>         being ($_ == 90210)    { die "B" }
>         having ($matcher)      { die "C" }
>     }
> 
> "being" should be mentally read as "it being that", and "having" as
> "having a".  In the example above, "having($matcher)" doesn't read well,
> but "having(Number)" and suchlike would flow nicely.

I do like 'when'.  But how about 'have' meaning 'when we have'?

    given ($stuff) {
        when ($_ eq 'string') { die "cloth" }
        when ($_ == 12345)    { die "hard" }
        have (Number)         { die "the death" }
    }

You could even imagine a question mark: Have a number? Ok, then ....

> 
> If we're mucking about with these keywords, we should also consider
> respelling "default", which reads poorly and seems to have been copied
> too directly from C.  An adverbial phrase is required to introduce a
> conditionally-executed block.  I suggest "generally" for the default
> action.

I think that is getting too long.  I have no problem with the name of
the keyword 'default'.

> For consistency, we should also have "generally" available as
> a postfix.

My immediate reaction is to think it very unperlish:

    do_stuff() generally;

I do not really care, though.  I do not expect ever to use 'default',
since it really serves no purpose.

    given ($thing) {
        default { do_stuff() }
        when(foo) { never_reached() } # an unfortunate gotcha
    }

    given ($thing) {
        when (foo) { reached() }
        do_stuff() # this *is* a default; the automatic 'break' that
                   # 'default' includes is superfluous in the only
                   # place where default makes sense
     }

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