develooper Front page | perl.perl5.porters | Postings from July 2020

Re: Types in Cor (and Perl)

Thread Previous
From:
Darren Duncan
Date:
July 13, 2020 09:24
Subject:
Re: Types in Cor (and Perl)
Message ID:
21c9b4ba-b350-3566-428f-49a5bb8a0f2f@darrenduncan.net
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 
typically-anonymous variables.

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 
that's implementation-dependent.

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

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About