Front page | perl.perl5.porters |
Postings from July 2020
Re: Types in Cor (and Perl)
From: Darren Duncan
July 13, 2020 09:24
Re: Types in Cor (and Perl)
Message ID: firstname.lastname@example.org
On 2020-07-13 1:43 a.m., Andy Xiao wrote:
> Hi Ovid,
> I think you might confuse value type and refence type. General speaking, a
> type of CS is divided by 2 set:
> one is value type, this is more or less pure data stored on memory, like int,
> uint, struct,(maybe including char)
> another is reference type, it does some abstraction and package on the real
> data for human , like class type, string etc.
> I think if Perl would add a type system, it'd better think about both above type.
Andy, yes you are right.
(Please see my previous reply to Ovid for context, which this is an addendum to.)
How I would characterize the distinction is that all types are value types, and
all values are immutable, but that some values are handles/references for
The actual immutable value is effectively the memory address of the variable,
but the format of the memory address is by default a black box to the user. In
a debugging situation the address typically is represented by an integer, but
So, following my definition of what value equality is, no way of telling X and Y
apart, it stands to reason that 2 handle/reference value appearances X and Y are
the same value if and only if they point to the same variable.
In a language where everything is an object, an object being mutable is the same
as that object being a handle/reference value, whereas an object that isn't
mutable is not a handle/reference.
In typical parlance, generic equality tests do a shallow/reference comparison
for mutable objects and they do a deep comparison for immutable ones.
Or to be more specific, if an immutable object has attributes of mutable types,
then comparison if the immutable object is only as deep as the mutable attributes.
A key advantage of defining general equality as I have is that it is guaranteed
to be fully deterministic. When you don't cross reference boundaries into
variables, you are guaranteed that any operation you do will produce the same
result every time, and so you can use that for indexing or other things with
your conclusions never becoming invalid.
I will point out that the generic equality test I mention is something that must
be built-in to the language and it must work for all types including
user-defined types, and users must not be able to override it. This is as basic
as the generic assignment operator, which users don't override either.
If users want to conceptually override the definition of equality, say to
support case-insensitive compares, they should have to name that something else.
See also Raku having distinct =:= and === and == and eq operators.
Note that comparing different types for generic equality is completely valid and
well-understood and logical; the operator simply returns false when given say a
number and a string. The signature of the operator is (Any,Any).
-- Darren Duncan