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

Re: sigil-optional subject clarification

L A Walsh
May 25, 2021 20:25
Re: sigil-optional subject clarification
Message ID:
This is meant to be a quick note.  I have a more thorough reply I've been
constructing for point "1", but on point 2, i.e.:
> 2) Going 'unnecessary-sigil' optional.
    There is a big difference between "getting rid of all sigils" and
"creating a language with no sigils", and what is stated in #2.

    The above has 2 important points: "unnecessary" and "optional"

Nothing in the above would require removing any sigils in existing programs
(or future programs).  Treating a sigil-less symbol as valid would require
that under current perl rules, the same symbol would fail to compile if 
strict" was used.  Example;

  use warning;
  use opsig; #optional_sigals

  my $x = 11;
  my $y = x + 5;

Under current "strict" rules, "x" would be flagged with an error.

Under "opsig", perl would, instead recognize that the only symbol
defined in that context named "x", is the 'my' statement in the previous

If the symbol could have an alternate meaning or definition, then perl
would flag it as an "exception".

If in the same example, there was an

  sub x { #do x-stuff }
or a statement like:

  our @x=(qw(array x things));

Then perl cannot know what type 'x' is and would flag any use
of a raw 'x' as an error.

Similarly, if the user tried to write:

  my $x = 11;
  my $y = x->[0];

they would get a similar error they would now get by saying

  my $y = $x->[0]; #as the 2nd statement:

Can't use string ("11") as an ARRAY ref while "oprefs" in use at -e line 2.

Anyway, need to run and hope this clarifies my intent -- that it was not
to create an incompatible replacement.  Just turn "strict" errors into
something useful under the right pragma.

> Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About