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

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

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

From:

Nicholas Clark

Date:

May 24, 2021 07:54

Subject:

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

Message ID:

20210524075401.GO9170@etla.org

Linda, Phillp:

On Sun, May 23, 2021 at 12:33:58PM -0700, L A Walsh wrote:

> 2) Going 'unnecessary-sigil' optional.


On Sun, May 23, 2021 at 09:16:46PM +0100, Philip R Brenan wrote:
> We can even remove sigils in cases where variable names are overloaded:

Neil has already written that "Perl is going to stay Perl"

https://www.nntp.perl.org/group/perl.perl5.porters/2021/05/msg260068.html

    We want to make perl a better Perl, not a different
    language. We're not going to switch to Raku's model for sigils, or
    change to . instead of ->, for example.

    Don't propose changes that go against these principles.


We are *NOT* going to remove sigils. Even in certain circumstances, as
getting the corner cases right for those is hard (see below)

Please stop suggesting changes that go against clear decisions of the PSC.

You are wasting everyone's time, and *I* certainly don't appreciate this.

On Sun, May 23, 2021 at 08:43:40PM +0100, Paul "LeoNerd" Evans wrote:
> On Sun, 23 May 2021 12:33:58 -0700
> L A Walsh <astara@tlinx.org> wrote:
> 
> > 2) Going 'unnecessary-sigil' optional.
> 
> My personal response here:
> 
> If you wanted Python, you know where to find it.

Given my above comments, I appreciate the frustration, but pithy one line
comments don't add value.

As part of a longer explanation, it would be different. For example:


On Mon, May 24, 2021 at 09:38:28AM +0300, Alexandr Evstigneev wrote:
> On Sun, May 23, 2021 at 10:35 PM L A Walsh <astara@tlinx.org> wrote:
> 
> > 2) Going 'unnecessary-sigil' optional.
> >
> > If a symbol has a unique type (SCALAR, sub, HASH, etc), and is declared
> > before use by 'whatever appropriate mechanism', and there is no introduced
> > ambiguity, then the sigil can be left off.  In any case of ambiguity or
> > where the same symbol is used with more than one type, or where the symbol
> > isn't defined, a sigil would be required in the same way it currently is.
> >
> > There are likely sub-issues associated with this, but past programs, that
> > use sigils would continue to execute the way they do now (compatibility).
> >
> 
> And how are new programs supposed to handle this?
> I can use the bare `foo` variable declared in my `Foo::Bar::somesub` and
> then, some other module adds `foo` sub to my namespace and looks like bare
> variable shadows this sub and this is kind  of unexpected.

Thanks for thinking this through, and writing a clear explanation.


So, "removing sigils" has been discussed and is not feasible


It is not happening. No more mails about it.

Nicholas Clark