9

So, from the documentation is almost clear what the three entities from the title are, but it is not very clear what their purpose is.

Constants are common in many languages. You don't want to write 3.14 all over your code and that's why you define a constant PI that, by the nature of the thing it represents, cannot be changed and that's why its value is constant in time.

Defining a variable bound to another entity with := is also almost clear but not really. If I bind a variable to 3.14, isn't it the same as defining a PI constant? Is $a := $b actually defining $a as an alias to $b or, as some other languages call it, a reference? Also, references are generally used in some languages to make it clear, in object construction or function calls, that you don't want to copy an object around, but why would it be useful, in the same scope, to have

$number_of_cakes = 4;
$also_the_number_of_cakes := $number_of_cakes;

?

Finally, the documentation explains how one can define a sigilless variable (that cannot be varied, so, actually, yet another kind of constant) but not why one would do that. What problems do sigilless variables solve? What's a practical scenario when a variable, a constant, a binding variable do not solve the problem that a sigilless variable solve?

pistacchio
  • 56,889
  • 107
  • 278
  • 420
  • 5
    You will generally chooses a sigilless variable when you don't know in advance what it's going to be bound to. If it could be a positional, an associative, scalar... then a sigilless variable is your thing. That's why it's used so often in method and sub protos. – jjmerelo Mar 17 '19 at 19:28
  • 1
    [jnthn expanding on JJ's point](https://stackoverflow.com/a/50401989/1077672). – raiph Mar 17 '19 at 19:40
  • "You will generally chooses a sigilless variable when you don't know in advance what it's going to be bound to." For readers confused by that, because they're thinking one *must* know if the code is `my \foo = ...`, JJ doesn't mean an ordinary variable but a *parameter* in a routine signature. – raiph Jan 01 '21 at 19:56

3 Answers3

12

Constants are common in many languages. You don't want to write 3.14 all over your code and that's why you define a constant PI that, by the nature of the thing it represents, cannot be changed and that's why its value is constant in time.

For that you use constant.

A constant is only initialized once, when first encountered during compilation, and never again, so its value remains constant throughout a program run. The compiler can rely on that. So can the reader -- provided they clearly understand what "value" means in this context.1

For example:

BEGIN my $bar = 42;

loop {
  constant foo = $bar;
  $bar++;
  last if $++ > 4;
  print foo; # 4242424242
}

Note that if you didn't have the BEGIN then the constant would be initialized and be stuck with a value of (Any).

I tend to leave off the sigil to somewhat reinforce the idea it's a constant but you can use a sigil if you prefer.

Defining a variable bound to another entity with := is also almost clear but not really. If I bind a variable to 3.14, isn't it the same as defining a PI constant? Is $a := $b actually defining $a as an alias to $b or, as some other languages call it, a reference?

Binding just binds the identifiers. If either changes, they both do:

my $a = 42;
my $b := $a;
$a++;
$b++;
say $a, $b; # 4444

Finally, the documentation explains how one can define a sigilless variable (that cannot be varied, so, actually, another kind of constant) but not why one would do that.

It can be varied if the thing bound is a variable. For example:

my $variable  = 42;        # puts the value 42 INTO $variable
my \variable  = $variable; # binds variable to $variable
say ++variable; # 43
my \variable2 = 42;        # binds variable2 to 42
say ++variable2;           # Cannot resolve caller prefix:<++>(Int:D);
                           # ... candidates ... require mutable arguments

I personally prefer to slash sigils if an identifier is bound to an immutable basic scalar value (eg 42) or other entirely immutable value (eg a typical List) and use a sigil otherwise. YMMV.

What problems do sigilless variables solve? What's a practical scenario when a variable, a constant, a binding variable do not solve the problem that a sigilless variable solve?

Please add comments if what's already in my answer (or another; I see someone else has posted one) leaves you with remaining questions.

Foonotes

1 See my answer to JJ's SO about use of constant with composite containers.

Community
  • 1
  • 1
raiph
  • 31,607
  • 3
  • 62
  • 111
8

That's not one but at 5 questions?

If I bind a variable to 3.14, isn't it the same as defining a PI constant?

Well, technically it would be except for the fact that 3.14 is a Rat, and pi (aka π) is a Num.

Is $a := $b actually defining $a as an alias to $b or, as some other languages call it, a reference?

It's an alias.

$number_of_cakes = 4; $also_the_number_of_cakes := $number_of_cakes;

There would be little point. However, sometimes it can be handy to alias something to an element in an array, or a key in a hash, to prevent repeated lookups:

my %foo;
my $bar := %foo<bar>;
++$bar for ^10;

What problems do sigilless variables solve?

Sigilless variables only solve a programming style issue, as far as I know. Some people, for whatever reason, prefer sigilless varriables. It makes it harder to interpolate, but others might find the extra curlies actually a good thing:

my answer := my $ = 42;
say "The answer is {answer}";

What's a practical scenario when a variable, a constant, a binding variable do not solve the problem that a sigilless variable solve?

In my view, sigilless variables do not solve a problem, but rather try to cater different programming styles. So I'm not sure what a correct answer to this question would be.

Elizabeth Mattijsen
  • 25,654
  • 3
  • 75
  • 105
1

Also constant is our scoped by default.

drclaw
  • 2,463
  • 9
  • 23