develooper Front page | perl.perl5.porters | Postings from February 2022

Re: Thoughts Towards Type Assertions (was: Re: Pre-RFC: builtin::functions for detecting numbers vs strings)

Thread Previous | Thread Next
Darren Duncan
February 25, 2022 05:32
Re: Thoughts Towards Type Assertions (was: Re: Pre-RFC: builtin::functions for detecting numbers vs strings)
Message ID:
This is a response to Paul's first message under the current thread title plus 
last message under the prior thread title.

First of all, I feel you generally seem to be going in the right direction with 
your explanations.

 From my perspective, there are 2 main use cases here and associated questions 
that BOTH need to be supported and easy to do, with respect to any given value:

1. CAN this value be USED AS a particular type of thing.
2. IS this value CANONICALLY a particular type of thing.

Scenario 1 is the most common for typical developers.  They want to do some kind 
of operation that requires inputs of particular types and they want to ensure 
that inputs they are given can be treated as those types in a deterministic way. 
  The test is a predicate, either the input can or can't be used as the desired 
type, and would be accepted or rejected accordingly.

Scenario 2 is possibly more niche, or also common, depending on the wider 
context, for developers.  They want to do some kind of operation whose logic 
dispatches to a type-specific version for each of the possible types of the 
input.  One critical use case is interchange with a more strongly typed format 
or system, JSON being a commonly cited example.  Another potential use case is 
supporting multi-subs where a variant is picked based on the argument type.  The 
test is a classification, such that every single value has exactly 1 MOST 
SPECIFIC TYPE that it maps to in a deterministic way.

The "most specific type" (MST) is about as specific as you can get that is 
significant to a user, and no further.  But in this context it ignores all 
user-defined types or blesses.

Examples of MST, all mutually disjoint, that I personally care about having in 
Perl are:

- Undefined/Null/etc - just 1 value
- Boolean - just 2 values, false and true
- Integer - a whole number of any magnitude
- Fraction/Float - a possibly fractional real number of any magnitude
- Text/String - a sequence of Unicode/ASCII character codepoints of any length
- Blob - a sequence of octets of any length
- Array/ArrayRef - a Perl hashref, usually not blessed
- Hash/HashRef - a Perl arrayref, usually not blessed
- Object - a Corinna object

For my most immediate significant projects, the second scenario about 
classification and canonicity is what I care about the most.  I want to be able 
to take arbitrary values and classify each deterministically into exactly 1 of 
the above list and/or 1 of a few other options not on that list as they exist.

I generally want the classification system to err on the side of treating a 
nonreference defined scalar as a string, that is, "123" and "123.0" are always 
classified as strings, and only 123 is classified as an integer or 123.0 as a 
float etc.  This is necessary for users to be able to have a choice, where they 
can be free to say they have "123" and want it to be treated as a string, in 
contrast to if that were canonically a number then they lose the choice.

In this context, things like Defined or Reference or Nonreference etc are union 
types that group some of the others, and they are not MSTs themselves.

Given that classification scenarios would often be used with switch statements 
or otherwise, there should be a single builtin function provided which returns 
the answer to, what is the canonical MST of this value, ignoring blesses or 
user-defined types.  It would be very similar to what reftype() etc do.  One 
then uses the result of that function as the input to the switch statement and 
then have a case for each of its possible results, which are mutually disjoint, 
so the order of the items in the switch statement doesn't matter.

I'm not too stuck on what the builtin functions are named, just that they exist, 
and a set exists usable for both of the main scenarios, predicates and disjoint 
most specific categories.

-- Darren Duncan

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