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

Re: Two further features, one definitely needed for survival, otherlikely needed.

From:
L A Walsh
Date:
May 27, 2021 05:39
Subject:
Re: Two further features, one definitely needed for survival, otherlikely needed.
Message ID:
60AF305B.3070607@tlinx.org
On 2021/05/23 13:16, Philip R Brenan wrote:
> We can even remove sigils in cases where variable names are overloaded:
>
> my $a = 1
> my @a = {2)
> my %a  = {3=>4}
>
> a[0] = 3;  # Clearly an array reference
> a{3} = 6;  # Clearly a hash reference
>   
----
    *Perhaps*, though my first inclination is not -- only because
I'm not certain that it might not be confused -- I'd prefer to leave
that for a future stage, since I've only thought through the case
of there being one form of a symbol defined.  I.e. I'm being
a conservative as possible to ensure there is no conflict with current
code.  At the very least, I think you may have meant 'my @a=();'?

> User defined operators can further ameliorate this situation:
>
>  a *@* 1 = 2;  # Assign an element to an array
>  a *%* 3 = 7;  # Assign to an element of a hash.
>   
----
    This may also be a possibility, however, clearly, using "user
defined operators" is a separate issue from using what is currently
an "error-space": something that would normally be an error under
the strict pragma.  I'm proposing a different behavior be allowed under
a different pragma.

> On Sun, May 23, 2021 at 8:44 PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
> wrote:
>
>   
>> My personal response here:
>>
>> If you wanted Python, you know where to find it.
>>     
----
    I wasn't aware that python used sigils.  How could you consider
a sigil optional syntax having anything to do with a language that
doesn't use sigils by default? 







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