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
