the following operation converts $x from a Rat to a FatRat

That's a a mutable "container" aka a variable (a Scalar in this case) containing one immutable value (a Rat) then another immutable value (a FatRat).

# Declare a new identifier $x and bind it to a new mutable Scalar cont
+ainer:
my $x;

# Assign a value into the Scalar:
$x                # An LHS reference to a Scalar returns the Scalar.
   =              # = is assignment. The LHS decides what to do with i
+t.
     9.9;         # Creates a new immutable Rat.

# VAR macro returns what the identifier is bound to:
say $x.VAR.^name; # Scalar -- the type of variable bound to $x.

# All other uses of $x or a Scalar on RHS return the value assigned in
+to the Scalar:
say $x;           # 9.9
say $x.^name;     # Rat -- the type of the value assigned into the Sca
+lar.
$x *= 2;          # This is equivalent to ...
$x = $x * 2;      # ... which assigns result of RHS expression into Sc
+alar on LHS.
say $x;           # 39.6
[download]

Hth.

That's a mutable "container" aka a variable (a Scalar in this case) containing one immutable value

I really do not understand the use of the term "immutable".
Is it perhaps meant to be some shorthand method of signifying that the numerator and denominator are co-prime ? (For this, the gmp C library documentation uses the term "canonical" - in the sense, I think, of "authoritative, standard, accepted".)
Admittedly, the connection between the meanings of "co-prime" and "immutable" seems very tenuous to me, but it's about all that I can come up with.

Cheers,
Rob

One thing's for sure -- you're confused! I apologize if the following still doesn't help and/or is aggravating.

I really do not understand the use of the term "immutable".

To me it means "never changes".

There are three exceptions:

Construction

A data item must go from uninitialized/undefined to initialized/defined:

my $foo := 42; # declares $foo at compile time, binds it to immutable 
+42 at run-time
BEGIN say $foo; # (Any)
$foo = 99; # Cannot assign to an immutable value
[download]

Destruction

Memory is of course reclaimed at the end of a process at the latest if not garbage collected earlier (when no more references to it exist).

Referencing mutable data

One can have a reference that is itself immutable but which refers to mutable data. (Rats aren't mutable. So please don't think "ah, maybe this is the issue". I'm just trying to be complete in elaborating on the precise meaning of "immutable" in P6.) Thus:

my @foo := (42, $);
@foo[1] = 99;
say @foo; # (42 99)
@foo[0] = 99; # Cannot modify an immutable Int
[download]

If your light bulb still hasn't lit up at least a little, perhaps it really is best for you to just wait until materials about P6 sufficiently improve (maybe years? maybe never?) and you have time to enjoy exploring them. (I don't think anyone can absorb new information well unless they're enjoying the process and it feels like you're very much not enjoying this at any level. I apologize if I've got that wrong.)

Alternatively, perhaps you could pick a line from my earlier comment in which I broke things down into tiny pieces, one that isn't clear to you, and we can then try to clear that up, and then another line, and so on?

You can give $x a type, but prepare to be disappointed.

> my Rat $x = 0.1;
> $x *= 0.1.FatRat;
Type check failed in assignment to $x; expected Rat but got FatRat (Fa
+tRat.new(1, 100))
[download]

Yeah, well. That is to be expected as it is akin to assigning an int64 to an int32. What surprises me is that

perl6 -e "my FatRat $r = 0.1"
[download]

throws the same error.


holli

You can lead your users to water, but alas, you cannot drown them.

Type check failed in assignment to $x; expected Rat but got FatRat

At least that Rat appears to be immutable ;-)

I need to study the documentation and spend some time working through it.

Cheers,
Rob

It makes sense that the compiler would be disappointed but that's because you told it to expect a Rat on the LHS but then put a FatRat on the RHS and "Arithmetic operations involving a FatRat and optionally Int or Rat objects return a FatRat, avoiding loss of precision."