Five (syntax) things that I would like to change in Perl

Tib - Dec 3 '20 - - Dev Community

Somewhat related to What are five things you hate about your favorite language? from brian d foy

There are some Perl syntax that I don't feel comfortable with.

Kid think

This is my list of 5 things ! 😃

Variant sigils

It is not original, but invariant sigils would make sense for me.

I'm not arguing to drop context or slices (even not at all) but I would feel better with invariant sigil (that simply shows what the container type is).

(Raku is doing this)

In the same kind of things, having $var different from @var different from %var (etc...) is cool... but dangerous.

Same

Array and hash declaration

I would prefer to use {} to declare hash (not hashref) and [] to declare array (not arrayref).

These symbols are just the same that we use to access the elements, it simply makes sense for me.

Working Perl :

# Hash 
my %h = ( k1 => "1", k2 => "2" ); 
print $h{'k2'};

# Array
my @a = ( "a", "b" ); 
print $a[1];

# Hashref
my $h = { k1 => "1", k2 => "2" }; 
print $h->{'k2'};

# Arrayref
my $a = [ "a", "b" ]; 
print $a->[1];
Enter fullscreen mode Exit fullscreen mode

Since {} is the symbol to access a hash key and [] the symbol to access a array index, why it is linked to an hash*ref* and an array*ref* ?

And what about simply reusing the reference operator \ for the refs ?

Imaginary code :

# Hash 
my %h = { k1 => "1", k2 => "2" }; # Same symbol to declare and access
print $h{'k2'}; 

# Array
my @a = [ "a", "b" ]; # Same symbol to declare and access
print $a[1]; 

# Hashref
my $h = \{ k1 => "1", k2 => "2" }; # \ is the "get ref" symbol
print $h->{'k2'}; 

# Arrayref
my $a = \[ "a", "b" ]; # \ is the "get ref" symbol
print $a->[1]; 
Enter fullscreen mode Exit fullscreen mode

Of course, I like the features like array/hash conversion, array flattening and fat comma, I'm just a bit confused by how we declare arrayref and hashref.

The missing comma

The justifiable but error prone missing comma when printing to filehandles :

print $fh ARGS
Enter fullscreen mode Exit fullscreen mode

I don't feel good with this :/

Sad

Better OO in the core

Ok (1), it's just a matter of installing a module...

Ok (2), it is coming with Cor 😃

Snoop

Still unclear about function prototypes or signatures

I'm really still unclear about what to use for function declaration. Some resources about it :

I NEED prototypes or function signatures.

I usually declare all my functions at the top of a file with comments :

# Describe fn
sub fn($$;$);
Enter fullscreen mode Exit fullscreen mode

I do this for clarity and because it checks parameters (if not called with &).
In addition, since I gather all predeclarations with comments, it gives an API for humans 😄

The "predeclaration" could also just be required (depending the ordering and if you call the sub without parenthesis) but that's not the main goal (again you can bypass with &).

Then I define function like this :

sub fn($$;$) {
    my $name = shift;
    my $age = shift;
    my $optional_comment = shift;

    ...
}
Enter fullscreen mode Exit fullscreen mode

That I prefer over :

sub fn($$;$) {
    my ($name, $age, $optional_comment) = @_;

    ...
}
Enter fullscreen mode Exit fullscreen mode

Or even worse (😱) :

sub fn($$,$) {
    print $_[0];
    print $_[1];
    print $_[2];

    ...
}
Enter fullscreen mode Exit fullscreen mode

But honestly, I don't know, signatures are marked experimental and prototypes should not be used because they change the behaviour of a function.

What is the right way then ?

Conclusion

That's it, that was my list ! 😃

List

What is yours ?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .