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

Re: Types in Cor (and Perl)

Thread Previous | Thread Next
Darren Duncan
July 13, 2020 20:21
Re: Types in Cor (and Perl)
Message ID:
On 2020-07-13 8:18 a.m., Ovid via perl5-porters wrote:
> If we make a distinction, I think the terminology could be improved to help 
> clarify the meaning. Maybe "built-in" versus "derived"? If we can pick 
> terminology which is self-defining, I think fewer misconceptions might occur.

I agree that this is much better.

The primary distinction I see for type categories is "system-defined"/"built-in" 
and "user-defined".  The first category assumes the user can not change it.

Generally speaking, whenever a type is defined by the system, language 
implementations have free reign to implement them how they want behind the 
scenes as long as the user-exposed behavior doesn't change, and there is a lot 
of latitude for special-case optimization.

Being system-defined does not have any relation in general to whether a type 
maps to something the hardware specifically knows about such as a "signed 32-bit 

But in practice it is best for a language to anticipate the hardware and provide 
some canonical way to have data types somehow that directly map to those so that 
the compiler/runtime doesn't have to be as clever to know when it can use them.

On a tangent, I feel that it is a hallmark of a modern language if a "big 
integer" / unlimited-size integer type is a standard built-in, or better yet is 
THE type used by idiomatic code.  Raku Int is an example of this.  In the Perl 5 
case this basically means Math::BigInt or such receiving special treatment and 
receiving syntax that it can be used as tersely as traditional scalars.  Behind 
the scenes, machine integers can still be used when the integers fit in them but 
promotion is more automatic, and no more overflows/etc.

-- Darren Duncan

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About