October 05, 2008
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.

The implementation would accept conversion from its base type, e.g. Positive.(real) can be constructed from a real. The constructor enforces dynamically the condition. Also, Positive.(real) accepts implicit conversion to real (no checking necessary).

There are many places in which Positive can be useful, most notably specifications of interfaces. For example:

Positive.(real) sqrt(Positive.(real) x);

These specifications are also efficient because checking for positivity is done outside sqrt; if you had a Positive.(real) to start with, there is no cascading checking necessary so there's one test less to do.

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?

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.

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.

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.
==============

I'm interesting in further arguments. This feature is a numbers issue (pun not intended), meaning it will be any good only if enough people find it useful enough to actually use it in their own code and libraries, therefore building momentum behind it.


Andrei
October 05, 2008
"Andrei Alexandrescu" wrote
> (Background: Walter has kindly allowed ".()" as an alternative to the ugly "!()" for template argument specifications.)

:(

Another case of multiple syntax possibilities.  What was wrong with !() ? I didn't consider it ugly at all.  In fact, I prefer it.

It's very alarming to me that something like this just has no problem getting in the language without community feedback.

> 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.

I wouldn't use it, if that helps at all.  Even if it was in Tango (i.e. not just because I don't use Phobos).

-Steve


October 05, 2008
Steven Schveighoffer wrote:
> "Andrei Alexandrescu" wrote
>> (Background: Walter has kindly allowed ".()" as an alternative to the ugly "!()" for template argument specifications.)
> 
> :(
> 
> Another case of multiple syntax possibilities.  What was wrong with !() ? I didn't consider it ugly at all.  In fact, I prefer it.
> 
> It's very alarming to me that something like this just has no problem getting in the language without community feedback.
> 
>> 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.
> 
> I wouldn't use it, if that helps at all.  Even if it was in Tango (i.e. not just because I don't use Phobos).

Seconded.
October 05, 2008
Andrei Alexandrescu wrote:
> 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.

I'm not a math major. But in college I took 4 years of math, up through integration in the complex plane and branch cuts (which I never did properly understand <g>). Every engineering/physics class was a math class. I never saw this notation. I am not suggesting it doesn't exist, just that it became commonplace fairly recently, or that it isn't commonplace at least at the undergraduate level. This plays into the numbers issue you mentioned.
October 05, 2008
On Sat, Oct 4, 2008 at 10:55 PM, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> "Andrei Alexandrescu" wrote
>> (Background: Walter has kindly allowed ".()" as an alternative to the ugly
>> "!()" for template argument specifications.)
>
> :(
>
> Another case of multiple syntax possibilities.  What was wrong with !() ? I didn't consider it ugly at all.  In fact, I prefer it.
>
> It's very alarming to me that something like this just has no problem getting in the language without community feedback.

Heartily agree.  Not that it means anything.
October 05, 2008
Steven Schveighoffer wrote:
> It's very alarming to me that something like this just has no problem getting in the language without community feedback.

It's there at the moment so we can look at it and see if we like it. I know Andrei likes it. Anyhow, this is the opportunity for community feedback.
October 05, 2008
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
October 05, 2008
Andrei Alexandrescu escribió:
> (Background: Walter has kindly allowed ".()" as an alternative to the ugly "!()" for template argument specifications.)
> 
> For example:
> 
> Positive.(real) sqrt(Positive.(real) x);

I can't read that. I see a bunch of calls and casts. !() was a little hard at first, but this is impossible.

Of course, this is just my opinion, I don't know what the others think about it...

Another problem, from an IDE perspective: "Positive." will trigger autocomplete of Positive's members, ugh.
October 05, 2008
Walter Bright wrote:
> Steven Schveighoffer wrote:
>> It's very alarming to me that something like this just has no problem getting in the language without community feedback.
> 
> It's there at the moment so we can look at it and see if we like it. I know Andrei likes it. Anyhow, this is the opportunity for community feedback.

To me, the !() syntax has always clearly communicated what's happening. 
 The exclamation mark signifies an assertion of sorts (using the English meaning of 'assertion', not the programming meaning).  With the dot syntax I'd always be wondering whether there was a function call taking place that I didn't know about.  Is there anything this change in syntax gives us over what we currently have?  If not, I don't want it.


Sean
October 05, 2008
"Walter Bright" wrote
> Steven Schveighoffer wrote:
>> It's very alarming to me that something like this just has no problem getting in the language without community feedback.
>
> It's there at the moment so we can look at it and see if we like it. I know Andrei likes it. Anyhow, this is the opportunity for community feedback.

Well, here is my feedback.

First, I hate it when D has two ways of doing something.  For example, C style array declarations, or function pointers.  But those have good reasons.  We want the new style because it's unambiguous and context-free, but we want the old style to allow easy porting of C code.

But this change has no qualities I can see except that Andrei thinks it looks better (at least, that's the only reason he's given).  There are not compatibility issues with C or some other language, it's just a new syntax that looks different.  Are there problems with the original !()?  Please give a reason for this addition besides asthetics, and then we can discuss the merits.  Or if the community overwhelmingly loves this new syntax, I guess that's a good reason.  Otherwise, I think it should be rejected on the simple principle of not fixing things that aren't broken.

-Steve


« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11
Top | Discussion index | About this forum | D home