Front page | perl.perl5.porters |
Postings from March 2022
On Mon, Mar 14, 2022 at 1:51 PM Darren Duncan <darren@darrenduncan.net> wrote: > Okay, I have even BETTER name proposals: > > - is_classified_as_number() > - is_classified_as_string() > - is_classified_as_boolean() > > See also https://docs.raku.org/routine/classify for precedent. > > The POINT here, as I see it, is we want to be able to take any given Perl > value > and deterministically classify it into EXACTLY ONE mutually exclusive type. > > This is all about, we have a value, sort it between various choices where > it > fits best. > > It doesn't exactly matter how we got to that point as long as a clear > decision > is made. This tends to correlate with decisions made on creation or use > but > using "classify" avoids implying things beyond the use case of sorting. > > As for "canon", I agree it is much less linguistically clear as to why I > chose > that, but what I was going for was as in "canonical works" or "authorized; > recognized; accepted", the idea that we made an official position on what > criteria of a Perl value sorts it as a number versus a string etc. > > But even if I still think "canon" makes sense, I put forth that "classify" > gets > the point across much better. > > I should say however, that my wider proposal is actually more of a > hierarchy > than a strict mutually exclusive decision. > > Loosely speaking, this for example: > > - is_classified_as_undef() > - is_classified_as_boolean() > - is_classified_as_number() > - is_classified_as_integer() > - is_classified_as_float() or is_classified_as_fraction() > - is_classified_as_string() > - is_classified_as_text() > - is_classified_as_blob() > - is_classified_as_array() > - is_classified_as_hash() > - is_classified_as_object() in the Corinna sense > > So all leaves of the hierarchy are mutually exclusive and every Perl value > is a > member of exactly 1 leaf, but when leaves have parent nodes, then when a > value > is a member of a child it is also a member of a parent. > > Critically this also means we can and should be able to have also: > > - most_specific_classified_type_of() > > ... or similarly named which results in a STRING like > "boolean"/"integer"/"float"/etc that one can then use in a given-when > expression > etc. > > Now I realize the subtypes of "string" here may be more complicated since > in > practice the same representations may overlap, so resolving that this time > could > be skipped if there isn't a good solution at this time, while still > keeping the > rest of what I said, and in fact the hierarchy approach intentionally > gives us > room to grow and evolve. > > The integer vs float thing we should be able to do right away though. > > Ovid and others, what do you think of that? > We are not discussing classification of values. Again, please bring that up in threads about typing and not here. -DanThread Previous | Thread Next