develooper Front page | perl.perl5.porters | Postings from June 2021

Re: RFC: Multiple-alias syntax for for

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
June 11, 2021 09:36
Subject:
Re: RFC: Multiple-alias syntax for for
Message ID:
20210611093640.GE16703@etla.org
On Thu, Jun 10, 2021 at 03:08:56PM +0100, Paul "LeoNerd" Evans wrote:
> On Thu, 10 Jun 2021 14:04:59 +0200
> Salvador FandiƱo <sfandino@gmail.com> wrote:
> 
> > This is probably going out of control but...
> > 
> > How about extending "for" with attributes?
> 
> I have often wanted that sort of thing (I call them "adverbs") in a
> huge number of other places in perl. Far too many cases to list all of
> them, but a couple of notable ones:
> 
>   $str =~ s:nth(2)/foo/bar/;  # substitute just the 2nd match

That's also already valid syntax (well, ish):

    $ perl -e '$str =~ s:nth(2)/foo/bar/;'
    Substitution pattern not terminated at -e line 1.

because it's s/// but with ':' instead of '/'

    Larry's 2nd Law of Language Redesign: Larry gets the colon.

I don't actually know what the 1st Law as.

However, I do know the rough backstory, and the relevant detail...

IIRC the rough backstory was that during the RFC process (and later)
*everyone* was proposing different syntax using a colon. Most of which
was mutually exclusive (ie any one person's plan blocked 6+ others...)

So Larry wanted to be clear that he got to pick the syntax that used the
colon, to get maximum value by solving as many important problems as
possible.



But, the relevant detail here is:

   $perl5 ? $ternary : $operator;

   $perl6 ?? $ternary !! $operator;

(spelled appropriately for the context)


For Perl, the ternary operator rules out a lot of uses of the colon because
in any expression, likely a ':' will need to be parseable as part of a
ternary.


> First problem is that the syntax is too ambiguous: 
> 
>   map:concurrent(4)
> 
> is a call to the function &concurrent, taking the params (4), and the
> statement happens to have a label `map:`. That colon notation gets in
> the way alllll the time.
> 
> Annoyingly, I can't think of a good solution that doesn't start to
> become whitespace-dependent; i.e. that
> 
>   map: concurrent(4)
> 
>   map :concurrent(4)
> 
> would need to have different meanings. And everyone is going to shoot
> me for that idea.

It seems calmer to run the thought experiment "What would Abigail think?"


I'd forgotten about labels. So, so far, "things that like the colon"

1) ternaries
2) labels
3) delimiters for q-like operators


Likewise, '.' works as a method call operator because concatenation became
'~', (and bitwise '~' is pushed onward...)

But the subtle part is that you also need matching became '~~'.

Without that change, you have '.=' morphing to '~=', but '=~' would still be
legal, so confusing legal syntax typos abound...


And this is part of the "Perl should stay Perl" conundrum.

1) How far can you bend syntax whilst still being understandable?
2) What existing other syntax is "getting in the way" of your good idea.


A lot of the stuff in the language-formerly-known-as-Perl-6 only works as
part of a *grand* redesign. It's difficult to cherry-pick out parts that
are unambiguously "useful to us" and "a good solution" because often they
depend on other things being changed to work well, if at all.

So adverbs starting `:` is one of these things - I think most of us think
that this is nice, obvious syntax, and we'd love to have it.

*but*

where we can use it is limited by at least 3 existing other uses of ':',
and it's not clear

1) how far that restricts it
2) whether attempting to remove those restrictions costs more than benefits

(and as ever, these are design trade offs, so different people value them
differently, and that's quite legitimate. Which just adds to the fun.)


Nicholas Clark

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