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