Front page | perl.perl5.porters |
Postings from July 2020
Re: Types in Cor (and Perl)
From: Andy Xiao
July 13, 2020 08:43
Re: Types in Cor (and Perl)
Message ID: HK0PR03MB305867160D10E762C793451E8A600@HK0PR03MB3058.apcprd03.prod.outlook.com
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.
From: Ovid via perl5-porters <firstname.lastname@example.org>
Sent: Monday, July 13, 2020 3:28 PM
To: Branislav Zahradník <email@example.com>; Perl5 Porters <firstname.lastname@example.org>; Darren Duncan <email@example.com>
Subject: Re: Types in Cor (and Perl)
> A type is fundamentally just a set of values, such as the set of integer values
> or the set of array values or the set of all values.
A tiny clarification. A type is a named set of values along with with the operations allowed on it. For example, both a Dollar and Euro type might contain the same set of values, with the same operations on them, but you can't add a Dollar and Euro together because semantically, that doesn't make sense. You also couldn't ask if one is greater than the other because, again, that doesn't make sense (this is one thing which annoys me about databases: they "protect" your data and offer almost no type safety).
Thus, something that would be awesome for a type system is not only allowing subsets, but type cloning (made up syntax):
define Dollar as Num;
define Euro as Num;
my $dollars :isa(Dollar) = 100;
my $euros :isa(Euro) = 200;
my $avg = ( $dollars + $euros )/2; # run-time exception
Powerful, on-the-fly safety to prevent a common error. They may derive from Num values, but because the type names are different, we do not automatically have operations defined between them.
As for objects, a class is merely a user-defined type. The set of values it can contain is complex and the methods are the allowed operations. I suspect that if our type system makes a huge, user-visible, distinction between these and built-in types, we might want to consider if a mistake is made. (I'm unsure on this case)
IT consulting, training, specializing in Perl, databases, and agile development
Buy my book! - http://bit.ly/beginning_perl
On Monday, 13 July 2020, 07:02:39 CEST, Darren Duncan <firstname.lastname@example.org> wrote:
On 2020-07-12 7:07 p.m., Branislav Zahradník wrote:
> Great point, question IMHO is do we mean/need/want types or constraints?
Yes we definitely do.
> - constraint is evaluated runtime
> - type is declared and trusted
I see types and constraints are fundamentally one and the same thing.
The most generic form of a type definition is a predicate (boolean-resulting)
monadic function that takes any value as input and results in true or false if
the value is a member of the type (set of values) or not.
Whether or not anything is evaluated at runtime or not is entirely dependent on
whether an input to that evaluation comes from the user or the environment,
whereas if everything we need to know is available at compile time it CAN be
evaluated at compile time. The simplest implementations would evaluate at
runtime but the more optimized the system is the more it moves to compile time.
This is related to the concept of folding.
> Child type can via inheritance break a constraint imposed by parent type.
That depends on how the child and parent types are defined. If the child is
defines as a subset of the parent, then it can't.
> Examples with primitive types look nice, but ... who uses primitives and strong
> types ?
Primitives and strong types are very frequently used.
The whole concept of primitive types is mostly arbitrary. For example, is a
character string a primitive type or is it an array of characters?
Strong types are not tied to primitive types, they are very separate concepts.
Generally strong typing means that if you declare something expects an actual
string, it will only accept a string and not just something that can stringify;
strong typing would require you to explicitly cast the other thing to the
string. Whereas weak typing would just let you use the thing that isn't a
string in contexts that specifically ask for a string.
Don't confuse generic types with weak typing; the former is explicitly saying a
wider range of values is accepted; the latter is more about ignoring declared
intentions and pounding square pegs into round holes.
-- Darren Duncan