yary wrote:
...
Also, the domain should define how to compare objects and could provide
details about whether the set is finite, countable or uncountable.
...
Sounds like a role "Domain" that provides methods (off the top of my head)-
ordering - returns Nil if the domain is unordered, or a method
implementing "cmp" if it is ordered
succ, pred- returns Nil if the domain is uncountable, or method
implementing "next item", "prior item" if countable.
Exactly.
count - returns Inf if it's an infinite domain, or count of objects if
finite. What if counting is an expensive operation?
In most cases, the developer will know whether the domain is infinite
and just hardwire the result to Inf.
Then the .. operator can accept anything that does Domain where
ordering is non-Nil, and the ... operator can add the condition that
succ/pred are non-Nil.
Yes.
Moreover, I have realized that Domains can solve a lot of other
problems, such as collations. In English, it makes sense to write
something like
'a' .. 'z'
but the Danish and Swedish counterparts are
'a' .. 'z' followed by 'æ', 'ø', 'å' (Danish)
and
'a' .. 'z' followed by 'ä', 'ö', 'å' (Swedish)
since there is only one 'z' in unicode (for obvious reasons), collation
is something separate from the charset, which can be provided in a
domain. Also, encoding magical month names becomes easy (the double
parens here are casting to a domain):
my $month = ((DateDomain['en_US', '%b']))'Jan';
$month++;
say $month; # Feb
...and even...
my $date = ((DateDomain['en_US', '%D']))'01/14/2001';
$date++;
say $date; # 01/15/2001
Also, this is an extension of the notion of subtypes, augmenting it with
ordering and some other relations. Next question is whether the domain
shouldn't also provide arithmetic.
There is a lot of plumbing to do to fully use this concept, but I
believe it could be really useful.
Regards,
Michael.
where
