Re: RCF for option enhanced type constraints

John Napiorkowski wrote:
> A question about constant types. Duncan, you mentioned that the 'EqualsTo'
hint would basically be making the type a constant (although they wouldn't be
exactly usable as normal constants since they'd stringify to their type registry
name, not their value). I've done:
> 
> 	package MyApp::Constants;
> 	use Sub::Exporter -setup => { exports => [ qw(NAME) ]};
> 	use constant NAME=>'john';
> 	...
> 	package MyApp::Types;
> 	use MyApp::Constants qw(NAME);
> 
> 	subtype AuthorName
> 	 as Str,
> 	 where {$_ eq NAME};

When I said 'constant', I was referring to the fact that any subtype defined 
using 'EqualTo' would be defining a *singleton* type, a type consisting of 
exactly one possible value, in which case any variable/attribute/etc declared to 
be of that type is known to always hold that single value, and so referencing 
that var/attr/etc is essentially referencing a constant.

I see limited uses for a singleton type definition in practice; probably its 
main use is if you use it in defining a subtype of some composite type, such 
that the subtype consists of all the parent type's values where a specific type 
attribute is a single value.  Although introspection is a good reason to have it 
as well.

Mind you, you can do that with IsOneOf also, in which case EqualTo is just 
another name for the IsOneOf case that takes a single element list.

> Enough to consider if some tighter integration between types and constants
might be warranted. The above is fine in terms of separation of concerns, but
doesn't provide the type of meta data about the nature of the constraint to
anyone using it that I'd like to give.

Well sure, if you want to declare a singleton type for the sole purpose of 
making introspection of the use of a single special value easier, go for it.

> Duncan, I had a few questions specifically to your comments:
> 
>>                 Precision
>>                 Scale
> 
> These have a problem of being, on the face of it, radix-specific.  You
> should generalize those into versions that also have radix parameters,
> where 2 and 10 are likely the most common values; or maybe you already had
> a radix parameter in mind.
> 
> So I added a Base hint for Num.  The intended usage is something like:
> 
> 	subtype as Num[Base=>10, Precision=>xxx, Scale=>yyy]
> 
> With the goal of constraining a number. I lifted this from the SQL types. Let
> me know if you think I am understanding your comment correctly.

Assuming that precision and scale are interpreted within the context of the 
base, for example if you say [Base=>2,Precision=>31,Scale=>7] means a binary 
number of up to 31 bits long with 7 after the radix point (or transpose 
Precision and Scale if I mixed up the meanings of those terms), then yes you 
understand me correctly.

-- Darren Duncan