www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why callers should explicitly document storage classes

reply Mehrdad <wfunction hotmail.com> writes:
Consider this example:

     // In module foo.d:
     void baz(bool condition, lazy int value)
     {
         if (condition)
             writeln(value);
     }

     // In module bar.d:
     import foo;
     bool someCondition() { return false; }
     void main()
     {
         auto vals = [1, 2, 3, 4];
         while (!vals.empty)
             baz(someCondition(), items.moveFront());
     }

There is **absolutely NO WAY** to figure out what's wrong at the calling 
site. You need to check /every/ method call and make sure nothing weird 
is happening (e.g. lazy), and it's pretty much impossible to figure it 
out unless you're intimately familiar with the entire library you're 
calling -- something which (obviously) doesn't scale.

I don't know of a similar example off the top of my head for out/ref, 
but the same idea applies.

Is this convincing enough that we need to document storage classes at 
the CALLING site, rather than just the CALLEE site?
Aug 14 2011
next sibling parent Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Mehrdad wrote:

 Consider this example:
 
      // In module foo.d:
      void baz(bool condition, lazy int value)
      {
          if (condition)
              writeln(value);
      }
 
      // In module bar.d:
      import foo;
      bool someCondition() { return false; }
      void main()
      {
          auto vals = [1, 2, 3, 4];
          while (!vals.empty)
              baz(someCondition(), items.moveFront());
      }
 
 There is **absolutely NO WAY** to figure out what's wrong at the calling
 site. You need to check /every/ method call and make sure nothing weird
 is happening (e.g. lazy), and it's pretty much impossible to figure it
 out unless you're intimately familiar with the entire library you're
 calling -- something which (obviously) doesn't scale.

I'm not convinced that intimately is the right word here. Lazy evaluation is a pretty big deal in the interface of a function, just like ref is. If you have no idea at all what a function does, there is no hope to figure out what the code at the call site does to begin with. Even without lazy/out/ref you could be passing an object with reference semantics to a function which mutates the object, same deal. Not everything is 'const correct', so this may also be surprising if you do not know the function.
 I don't know of a similar example off the top of my head for out/ref,
 but the same idea applies.
 
 Is this convincing enough that we need to document storage classes at
 the CALLING site, rather than just the CALLEE site?

Do you mean literally documenting it or having the compiler require you to state the storage class? If the first, I'd say it depends on the context. The enforce function in phobos for example is clear and well known enough to leave it out. I would not want the latter. But yes, if it's not clear enough then it's a good idea. Preferably it would be clear from the function name and purpose how it operates on the parameters though.
Aug 14 2011
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/14/2011 01:34 PM, Mehrdad wrote:
 Consider this example:

 // In module foo.d:
 void baz(bool condition, lazy int value)
 {
 if (condition)
 writeln(value);
 }

 // In module bar.d:
 import foo;
 bool someCondition() { return false; }
 void main()
 {
 auto vals = [1, 2, 3, 4];
 while (!vals.empty)
 baz(someCondition(), items.moveFront());
 }

 There is **absolutely NO WAY** to figure out what's wrong at the calling
 site. You need to check /every/ method call and make sure nothing weird
 is happening (e.g. lazy), and it's pretty much impossible to figure it
 out unless you're intimately familiar with the entire library you're
 calling -- something which (obviously) doesn't scale.

 I don't know of a similar example off the top of my head for out/ref,
 but the same idea applies.

 Is this convincing enough that we need to document storage classes at
 the CALLING site, rather than just the CALLEE site?

Basically, as I see it what is wrong is that the function is called "baz" (and maybe that lazy arguments are allowed to be side-effecting). out/ref: int x=100; foo(x); assert(x==100);
Aug 14 2011
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sun, 14 Aug 2011 14:34:46 +0300, Mehrdad <wfunction hotmail.com> wrote:

 Consider this example:

      // In module foo.d:
      void baz(bool condition, lazy int value)
      {
          if (condition)
              writeln(value);
      }

      // In module bar.d:
      import foo;
      bool someCondition() { return false; }
      void main()
      {
          auto vals = [1, 2, 3, 4];
          while (!vals.empty)
              baz(someCondition(), items.moveFront());
      }

 There is **absolutely NO WAY** to figure out what's wrong at the calling  
 site. You need to check /every/ method call and make sure nothing weird  
 is happening (e.g. lazy), and it's pretty much impossible to figure it  
 out unless you're intimately familiar with the entire library you're  
 calling -- something which (obviously) doesn't scale.

 I don't know of a similar example off the top of my head for out/ref,  
 but the same idea applies.

 Is this convincing enough that we need to document storage classes at  
 the CALLING site, rather than just the CALLEE site?

I've raised this issue during voting for std.parallelism. I think the consensus was that "lazy" before lazy arguments would be appropriate, but "ref" would be mostly pointless, due to complex and reference types. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Aug 14 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/14/2011 05:36 PM, Vladimir Panteleev wrote:
 On Sun, 14 Aug 2011 14:34:46 +0300, Mehrdad <wfunction hotmail.com> wrote:

 Consider this example:

 // In module foo.d:
 void baz(bool condition, lazy int value)
 {
 if (condition)
 writeln(value);
 }

 // In module bar.d:
 import foo;
 bool someCondition() { return false; }
 void main()
 {
 auto vals = [1, 2, 3, 4];
 while (!vals.empty)
 baz(someCondition(), items.moveFront());
 }

 There is **absolutely NO WAY** to figure out what's wrong at the
 calling site. You need to check /every/ method call and make sure
 nothing weird is happening (e.g. lazy), and it's pretty much
 impossible to figure it out unless you're intimately familiar with the
 entire library you're calling -- something which (obviously) doesn't
 scale.

 I don't know of a similar example off the top of my head for out/ref,
 but the same idea applies.

 Is this convincing enough that we need to document storage classes at
 the CALLING site, rather than just the CALLEE site?

I've raised this issue during voting for std.parallelism. I think the consensus was that "lazy" before lazy arguments would be appropriate, but "ref" would be mostly pointless, due to complex and reference types.

requiring lazy before lazy arguments basically destroys the reason for lazy being in the language: int foo(lazy 2*3); is not better than int foo({return 2*3});
Aug 14 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/14/2011 10:00 PM, Vladimir Panteleev wrote:
 On Sun, 14 Aug 2011 22:48:18 +0300, Timon Gehr <timon.gehr gmx.ch> wrote:

 requiring lazy before lazy arguments basically destroys the reason for
 lazy being in the language:

 int foo(lazy 2*3);

 is not better than

 int foo({return 2*3});

What about requiring "lazy" only for non-pure delegates?

Actually I would rather require lazy arguments to be pure, so that they can be guaranteed to be executed at most once.
Aug 14 2011
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/14/2011 10:36 PM, Jonathan M Davis wrote:
 On Sunday, August 14, 2011 22:25:36 Timon Gehr wrote:
 On 08/14/2011 10:00 PM, Vladimir Panteleev wrote:
 On Sun, 14 Aug 2011 22:48:18 +0300, Timon Gehr<timon.gehr gmx.ch>  wrote:
 requiring lazy before lazy arguments basically destroys the reason for
 lazy being in the language:

 int foo(lazy 2*3);

 is not better than

 int foo({return 2*3});

What about requiring "lazy" only for non-pure delegates?

Actually I would rather require lazy arguments to be pure, so that they can be guaranteed to be executed at most once.

That still wouldn't be guaranteed, since pure function calls are only optimized out if they're strongly pure and in the same expression. You can't rely on calls to pure functions being optimized. - Jonathan M Davis

My point was, that if lazy arguments were required to be pure, such a thing _could_ then be guaranteed independently from optimizations that may or may not take place on general pure functions.
Aug 14 2011
prev sibling parent kennytm <kennytm gmail.com> writes:
Timon Gehr <timon.gehr gmx.ch> wrote:
 On 08/14/2011 10:00 PM, Vladimir Panteleev wrote:
 On Sun, 14 Aug 2011 22:48:18 +0300, Timon Gehr <timon.gehr gmx.ch> wrote:
 
 requiring lazy before lazy arguments basically destroys the reason for
 lazy being in the language:
 
 int foo(lazy 2*3);
 
 is not better than
 
 int foo({return 2*3});

What about requiring "lazy" only for non-pure delegates?

Actually I would rather require lazy arguments to be pure, so that they can be guaranteed to be executed at most once.

One problem: It is expected that the lazy argument can be re-evaluated. D's `lazy` is actually call-by-name, which allowed stuff like ---- void dotimes(int count, lazy void exp) { for (int i = 0; i < count; i++) exp(); } void foo() { int x = 0; dotimes(10, writef(x++)); } ---- as documented in http://www.d-programming-language.org/lazy-evaluation.html
Aug 14 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sun, 14 Aug 2011 22:48:18 +0300, Timon Gehr <timon.gehr gmx.ch> wrote:

 requiring lazy before lazy arguments basically destroys the reason for  
 lazy being in the language:

 int foo(lazy 2*3);

 is not better than

 int foo({return 2*3});

What about requiring "lazy" only for non-pure delegates? -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Aug 14 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, August 14, 2011 22:25:36 Timon Gehr wrote:
 On 08/14/2011 10:00 PM, Vladimir Panteleev wrote:
 On Sun, 14 Aug 2011 22:48:18 +0300, Timon Gehr <timon.gehr gmx.ch> wrote:
 requiring lazy before lazy arguments basically destroys the reason for
 lazy being in the language:
 
 int foo(lazy 2*3);
 
 is not better than
 
 int foo({return 2*3});

What about requiring "lazy" only for non-pure delegates?

Actually I would rather require lazy arguments to be pure, so that they can be guaranteed to be executed at most once.

That still wouldn't be guaranteed, since pure function calls are only optimized out if they're strongly pure and in the same expression. You can't rely on calls to pure functions being optimized. - Jonathan M Davis
Aug 14 2011
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sun, 14 Aug 2011 22:00:34 +0200, Vladimir Panteleev  
<vladimir thecybershadow.net> wrote:

 On Sun, 14 Aug 2011 22:48:18 +0300, Timon Gehr <timon.gehr gmx.ch> wrote:

 requiring lazy before lazy arguments basically destroys the reason for  
 lazy being in the language:

 int foo(lazy 2*3);

 is not better than

 int foo({return 2*3});

What about requiring "lazy" only for non-pure delegates?

I also thought of this idea. Now that pure inference is (being) added to the language, this seems doable and good. -- Simen
Aug 14 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, August 14, 2011 23:20:12 Timon Gehr wrote:
 On 08/14/2011 10:36 PM, Jonathan M Davis wrote:
 On Sunday, August 14, 2011 22:25:36 Timon Gehr wrote:
 On 08/14/2011 10:00 PM, Vladimir Panteleev wrote:
 On Sun, 14 Aug 2011 22:48:18 +0300, Timon Gehr<timon.gehr gmx.ch>  




 requiring lazy before lazy arguments basically destroys the reason
 for
 lazy being in the language:
 
 int foo(lazy 2*3);
 
 is not better than
 
 int foo({return 2*3});

What about requiring "lazy" only for non-pure delegates?

Actually I would rather require lazy arguments to be pure, so that they can be guaranteed to be executed at most once.

That still wouldn't be guaranteed, since pure function calls are only optimized out if they're strongly pure and in the same expression. You can't rely on calls to pure functions being optimized. - Jonathan M Davis

My point was, that if lazy arguments were required to be pure, such a thing _could_ then be guaranteed independently from optimizations that may or may not take place on general pure functions.

Yes. In theory. It would depend on what Walter was willing to do with the language and the compiler though. At present, pure is purely an optimization and not use to affect semantics at all. However, I'd actually argue that lazy delegates should be effectively treated as pure anyway. Conceptually, what you're doing is delaying the execution of the expression in case it isn't needed. I don't see any reason why the end result should be any different from passing a non-lazy argument. As such, the lazy argument should only be called once regardless. It wouldn't surprise me at all if the implementation doesn't work that way, but I'd argue that it should regardless of purity. From the standpoint of the function, the lazy argument is just like any other argument in terms of its value, and IMHO it should be treated that way. - Jonathan M Davis
Aug 14 2011
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On Sunday, August 14, 2011 2:30:39 PM, Jonathan M Davis wrote:
 On Sunday, August 14, 2011 23:20:12 Timon Gehr wrote:
 On 08/14/2011 10:36 PM, Jonathan M Davis wrote:
 On Sunday, August 14, 2011 22:25:36 Timon Gehr wrote:
 On 08/14/2011 10:00 PM, Vladimir Panteleev wrote:
 On Sun, 14 Aug 2011 22:48:18 +0300, Timon Gehr<timon.gehr gmx.ch>  




 requiring lazy before lazy arguments basically destroys the reason
 for
 lazy being in the language:

 int foo(lazy 2*3);

 is not better than

 int foo({return 2*3});

What about requiring "lazy" only for non-pure delegates?

Actually I would rather require lazy arguments to be pure, so that they can be guaranteed to be executed at most once.

That still wouldn't be guaranteed, since pure function calls are only optimized out if they're strongly pure and in the same expression. You can't rely on calls to pure function



 - Jonathan M Davis

My point was, that if lazy arguments were required to be pure, such a thing _could_ then be guaranteed independently from optimizations that may or may not take place on general pure functions.

Yes. In theory. It would depend on what Walter was willing to do with the language and the compiler though. At present, pure is purely an optimization and not use to affect semantics at all.

The pure keyword doesn't _change_ semantics, but it very much affects semantics, through restriction and the guarantees it provides. The restrictions help enforce some very specific and broadly useful behaviors. But you know this.
 However, I'd actually argue that lazy delegates should be effectively treated 
 as pure anyway. Conceptually, what you're doing is delaying the execution of 
 the expression in case it isn't needed. I don't see any reason why the end 
 result should be any different from passing a non-lazy a

 lazy argument should only be called once regardless. It wouldn't surprise me 
 at all if the implementation doesn't work that way, but I'd argue that it 
 should regardless of purity. From the standpoint of the function, the lazy 
 argument is just like any other argument in terms of its value, and IMHO it 
 should be treated that way.

That's not the way it behaves, or is defined to behave. Lazy parameters are executed 0-N times, entirely based on the implementation of the method itself. It _could_ be re-done to mean 0 or 1, but that's still not always 1. If it was, might as well kill the lazy concept.
 - Jonathan M Davis

Aug 14 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, August 14, 2011 17:39:29 Brad Roberts wrote:
 On Sunday, August 14, 2011 2:30:39 PM, Jonathan M Davis wrote:
 On Sunday, August 14, 2011 23:20:12 Timon Gehr wrote:
 On 08/14/2011 10:36 PM, Jonathan M Davis wrote:
 On Sunday, August 14, 2011 22:25:36 Timon Gehr wrote:
 On 08/14/2011 10:00 PM, Vladimir Panteleev wrote:
 On Sun, 14 Aug 2011 22:48:18 +0300, Timon
 Gehr<timon.gehr gmx.ch>




wrote:
 requiring lazy before lazy arguments basically destroys the
 reason
 for
 lazy being in the language:
 
 int foo(lazy 2*3);
 
 is not better than
 
 int foo({return 2*3});

What about requiring "lazy" only for non-pure delegates?

Actually I would rather require lazy arguments to be pure, so that they can be guaranteed to be executed at most once.

That still wouldn't be guaranteed, since pure function calls are only optimized out if they're strongly pure and in the same expression. You can't rely on calls to pure function



s being optimized.
 - Jonathan M Davis

My point was, that if lazy arguments were required to be pure, such a thing _could_ then be guaranteed independently from optimizations that may or may not take place on general pure functions.

Yes. In theory. It would depend on what Walter was willing to do with the language and the compiler though. At present, pure is purely an optimization and not use to affect semantics at all.

The pure keyword doesn't _change_ semantics, but it very much affects semantics, through restriction and the guarantees it provides. The restrictions help enforce some very specific and broadly useful behaviors. But you know this.
 However, I'd actually argue that lazy delegates should be effectively
 treated as pure anyway. Conceptually, what you're doing is delaying the
 execution of the expression in case it isn't needed. I don't see any
 reason why the end result should be any different from passing a
 non-lazy a

rgument. As such, the
 lazy argument should only be called once regardless. It wouldn't
 surprise me at all if the implementation doesn't work that way, but I'd
 argue that it should regardless of purity. From the standpoint of the
 function, the lazy argument is just like any other argument in terms of
 its value, and IMHO it should be treated that way.

That's not the way it behaves, or is defined to behave. Lazy parameters are executed 0-N times, entirely based on the implementation of the method itself. It _could_ be re-done to mean 0 or 1, but that's still not always 1. If it was, might as well kill the lazy concept.

Oh, I know that it's not always 1, and I'm not suggesting that it always be 1. I'm suggesting that it always be 0 or 1, and that it not actually be called multiple times even if it's referenced multiple times. I don't see why there is any value in having it called multiple times. In concept at least, a non- lazy parameter is the same as a non-lazy except that it isn't evaluated unless it's used. And so I don't see why you'd want to be evaluating it multiple times except that it's probably easier to implement that way. - Jonathan M Davis
Aug 14 2011