Positive

[Sean Kelly]

Andrei Alexandrescu wrote:
> Hello,
> 
> 
> (Background: Walter has kindly allowed ".()" as an alternative to the 
> ugly "!()" for template argument specifications.)
> 
> Just a quick question - I am feeling an increasing desire to add a 
> template called Positive to std.typecons. Then Positive.(real) would 
> restrict its values to only positive real numbers etc.

Sounds like range-restricted values, which people have been asking for 
as a language feature for ages.  The idea has merit.

> However, there is also the risk that Positive has the same fate the many 
> SafeInt implementation have had in C++: many defined them, nobody used 
> them. What do you think? If you had Positive in std and felt like 
> crunching some numbers, would you use it?

See below.

> In order to get things really started, there's already been an exchange 
> with Walter on the matter. His reply was (I haven't asked for 
> permission, but I'm pretty sure he'd agree making it public):
> 
> ==============
> Honestly, I wouldn't use it. I'd rather have an in contract for sqrt 
> that asserts the argument is positive. Also, this opens the door to 
> Negative, NegativeOrZero, ZeroOrInfinity, Odd, Even, Prime, 
> SixOrFifteen, etc.
> ==============
> 
> My answer to that was:
> 
> ==============
> About contracts: Let me explain how I think that's inferior to Positive 
> in two ways.
> 
> 1. Enough functions are defined on positive numbers only, to justify 
> factoring that contract out of the functions themselves.

So you're saying the problem with contracts here is code duplication? 
I'm not sure I follow.

> 2. The efficiency perk is that when using several such functions 
> together, there's only one check; once in Positive-land, no more checks 
> are necessary.

To be fair, there's one check for each time such a value is constructed 
or altered.  So you're simply assuming that the checked value will be 
constructed and then never altered.  But how is this different from 
using contracts?

I like the idea of checked values for safety, but I think efficiency 
concerns would prevent me from using them for actual work.  For example, 
let's say that I'm performing a bunch of computations.  I only really 
want to check whether the result is in range--I don't care about the 
intermediate values.  So I'd be inclined to forgo the use of checked 
values for the actual work and simply return a checked type at the end. 
  But this is exactly how contracts work!  Why would I bother with 
checked values if I can do the same checking in in/out clauses?

> About proliferation of types: I don't think that follows at all. Math 
> found positive numbers special enough to dedicate them a special 
> notation (|R with subscript "+"). There's also a special notation for 
> nonzero real numbers (|R with superscript "*"). There is no special 
> notation for any of the sets you mentioned. That is bound to mean 
> something.

It's clearly as important to describe the attributes of a variable in 
math as it is in programming.  So mathematicians settled on the notation 
you mention, and programmers have largely settled on the use of 
contracts.  There may still be some value in more math-like notation in 
programming, but I don't personally see much of a need for it in this 
case.  Like Walter, I'd continue to use contracts unless some compelling 
reason can be provided for using this notation instead.


Sean