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

Re: Types in Cor (and Perl)

Thread Previous | Thread Next
From:
Ovid via perl5-porters
Date:
July 13, 2020 07:28
Subject:
Re: Types in Cor (and Perl)
Message ID:
2104492602.473504.1594625302086@mail.yahoo.com
> 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)

Best,Ovid
-- 
IT consulting, training, specializing in Perl, databases, and agile developmenthttp://www.allaroundtheworld.fr/. 
Buy my book! - http://bit.ly/beginning_perl 

    On Monday, 13 July 2020, 07:02:39 CEST, Darren Duncan <darren@darrenduncan.net> 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.

> Difference:
> - constraint is evaluated runtime
> - type is declared and trusted

Not necessarily.

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
  
Thread Previous | Thread Next


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