On 2016-10-30 5:45 AM, yary wrote:
I'm not sure I entirely understand the proposal- does it change Inf aka ∞ ?


Part of the issue I think is that the existing "Inf" aka "∞" don't seem to be very clearly defined.

What I could find so far, at least with respect to Ranges, is that they are just syntactic alternatives to the Whatever *.

They don't seem to be actual typed values that one can say use as declared types for things.

Otherwise I like it, and prefer the X::NegInf and X::PosInf,spellings as being
easy-to-understand & a good Huffman-encoding.

Ok.

Before/AfterEverything are also easy to understand, and would be as natural to
use for sorting strings, eg. for saying if a database NULL should go before the
empty string or after everything else. On the other hand, if I'doing something
with tangents and handling pi/2, I'd rather be thinking about PosInf as my
exception and not AfterEverything.

So, the main thing that I think should exist is a generic before/after-everything concept so that it can be used to indicate that generic intervals are unbounded at either end and that generic 'cmp' etc are automatically defined for every other type and them and use as identity values for min/max.

At the same time, I think some people would want to distinguish between these and a mathematical concept of infinity in a similar manner that people distinguish orderable and ordered and ordinal etc.

What I mean by the latter is, "ordered" and "ordinal" have rather precise meanings in set theory or mathematics etc, meanings that don't apply to a lot of data types we tend to sort on. For example, ordered/ordinal strictly speaking wouldn't apply to character strings and they may not apply consistently to the general case of rational numbers and so on; for some types we just want to be able to sort them deterministically but the actual sort order might not be meaningful within the domain. So I made up the term "orderable" to refer to what generic "cmp" or SQL "order by" etc do.

The before/after-everything singleton are meant specifically to apply to this "orderable" concept.

So, having that, the question is whether we want to have distinct infinity concepts for numbers from those, and I suspect we might. In maths we have directional infinities on a line, but there's also the concept of something being infinite that is not directional such as an unbounded volume, and there's also countable vs uncountable infinities etc. We may not want to imply any of those with our before/after-everything concept which is meant to serve a different purpose.

X::BE and X::AE are too short to use outside of this discussion, especially as
"BE" is the common verb "be."

Maybe X::OBE and X::OAE for "ordered before/after everything"?

Anyway, this part is bike-shedding, my main point is that the singletons simply exist and what their properties are.

Before/AfterEverything ... would be as natural to
use for sorting strings, eg. for saying if a database NULL should go before the
empty string or after everything else.

So, now this brings up a different thing.

A Perl 6 analogy to a SQL Null would ALSO be a Failure singleton type, for example X::NoReason, basically it means that we don't have a normal value of the domain here AND we are giving absolutely no explanation for why the normal value is missing. A SQL Null in general means means "we don't have a normal value and we aren't saying why", it does NOT mean "not applicable" or "unknown" or "missing" or "not matched" or anything like that, it doesn't even say which of those it is.

As far as I could tell the Perl 6 Nil singleton had this X::NoReason meaning, but if it actually doesn't, then we should have a new X::NoReason to be more explicit about that. This would mean that a Perl 6 Nil actually IS giving a reason why the normal value is absent.

As a final note today, I will mention that the subject of this email thread is relevant to this thing that I'm working on, a DBI for Perl 6 with a PSGI/Plack inspired design, meaning a no-mandatory-shared-code database interface:

https://github.com/muldis/Muldis-DBI-Duck-Coupling-Perl6/blob/master/lib/Muldis/DBI/Duck_Coupling/API.pod

-- Darren Duncan

Reply via email to