www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DIP 1016 should use expression lowering, not statement lowering

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
While writing this example:

int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
if (alloc.reallocate(a, 200 * int.sizeof))
{
     assert(a.length == 200);
}

=====>

int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
void[] __temp0 = a;
if (alloc.reallocate(__temp0, 200 * int.sizeof)
{
     assert(a.length == 200);
}

I noticed a problem - the lowering as informally described in DIP 1016 
makes it difficult to figure how function calls present in control 
statements like if, while, etc. should behave. Where should the 
temporary go? An expression-based lowering clarifies everything. A 
statement-based lowering would need to work on a case basis for all 
statements involving expressions.


Andrei
Jan 29
next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Tuesday, 29 January 2019 at 11:52:40 UTC, Andrei Alexandrescu 
wrote:
 While writing this example:

 int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
 if (alloc.reallocate(a, 200 * int.sizeof))
 {
     assert(a.length == 200);
 }

 =====>

 int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
 void[] __temp0 = a;
 if (alloc.reallocate(__temp0, 200 * int.sizeof)
 {
     assert(a.length == 200);
 }

 I noticed a problem - the lowering as informally described in 
 DIP 1016 makes it difficult to figure how function calls 
 present in control statements like if, while, etc. should 
 behave. Where should the temporary go? An expression-based 
 lowering clarifies everything. A statement-based lowering would 
 need to work on a case basis for all statements involving 
 expressions.
On the contrary, an expression lowering cannot inject temporary declarations and is impossible. The correct lowering in the case for `if` & friends follows the form of C++ initialiser conditions(?) i.e: if (auto val = expr(); val) { ... }, or the slightly more ugly valid D: if ((){return expr(); }()) { ... } this lambdification will work for just about anything: if, while, assert...
Jan 29
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 1/29/19 10:44 AM, Nicholas Wilson wrote:
 On Tuesday, 29 January 2019 at 11:52:40 UTC, Andrei Alexandrescu wrote:
 While writing this example:

 int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
 if (alloc.reallocate(a, 200 * int.sizeof))
 {
     assert(a.length == 200);
 }

 =====>

 int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
 void[] __temp0 = a;
 if (alloc.reallocate(__temp0, 200 * int.sizeof)
 {
     assert(a.length == 200);
 }

 I noticed a problem - the lowering as informally described in DIP 1016 
 makes it difficult to figure how function calls present in control 
 statements like if, while, etc. should behave. Where should the 
 temporary go? An expression-based lowering clarifies everything. A 
 statement-based lowering would need to work on a case basis for all 
 statements involving expressions.
On the contrary, an expression lowering cannot inject temporary declarations and is impossible. The correct lowering in the case for `if` & friends follows the form of C++ initialiser conditions(?) i.e:  if (auto val = expr(); val) { ... },
Since we don't have these constructs, lowering would need to explain what happens here. Not difficult, but would be nice if we could avoid.
   or the slightly more ugly valid D:
 
   if ((){return expr(); }()) { ... }
 
 this lambdification will work for just about anything: if, while, assert...
Yes, converting to lambdas is nice and easy and requires no statement enumeration - just lower expressions to lambdas and be done with it. It's okay if the resulting code is ugly, it won't be user-visible.
Jan 29
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 29 January 2019 at 15:48:23 UTC, Andrei Alexandrescu 
wrote:
 On 1/29/19 10:44 AM, Nicholas Wilson wrote:
   if (auto val = expr(); val) { ... },
Since we don't have these constructs, lowering would need to explain what happens here.
Nitpick, but D has something very similar to that: if(auto val = expr()) { ... } it just depends on val implicitly casting to bool.
 It's okay if the resulting code is ugly, it won't be 
 user-visible.
We do have to be careful about this - error messages sometimes leak that ugly code out.
Jan 29
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 1/29/19 10:57 AM, Adam D. Ruppe wrote:
 On Tuesday, 29 January 2019 at 15:48:23 UTC, Andrei Alexandrescu wrote:
 On 1/29/19 10:44 AM, Nicholas Wilson wrote:
   if (auto val = expr(); val) { ... },
Since we don't have these constructs, lowering would need to explain what happens here.
Nitpick, but D has something very similar to that: if(auto val = expr()) { ... } it just depends on val implicitly casting to bool.
 It's okay if the resulting code is ugly, it won't be user-visible.
We do have to be careful about this - error messages sometimes leak that ugly code out.
Yah, it did happen in the past that implementations have been switched from lowering to a dedicated case. Lowerings do remain a terrific tool for conveying semantics and DIP authors should not worry about implementation details.
Jan 29
prev sibling parent Rubn <where is.this> writes:
On Tuesday, 29 January 2019 at 15:44:02 UTC, Nicholas Wilson 
wrote:
 On Tuesday, 29 January 2019 at 11:52:40 UTC, Andrei 
 Alexandrescu wrote:
 While writing this example:

 int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
 if (alloc.reallocate(a, 200 * int.sizeof))
 {
     assert(a.length == 200);
 }

 =====>

 int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
 void[] __temp0 = a;
 if (alloc.reallocate(__temp0, 200 * int.sizeof)
 {
     assert(a.length == 200);
 }

 I noticed a problem - the lowering as informally described in 
 DIP 1016 makes it difficult to figure how function calls 
 present in control statements like if, while, etc. should 
 behave. Where should the temporary go? An expression-based 
 lowering clarifies everything. A statement-based lowering 
 would need to work on a case basis for all statements 
 involving expressions.
On the contrary, an expression lowering cannot inject temporary declarations and is impossible. The correct lowering in the case for `if` & friends follows the form of C++ initialiser conditions(?) i.e: if (auto val = expr(); val) { ... }, or the slightly more ugly valid D: if ((){return expr(); }()) { ... } this lambdification will work for just about anything: if, while, assert...
If it a condition then you can do the following in C++: if(int* val = expr()) { // use val, not nullptr } Where it is useful is in the following case: if(int val = expr(); val != -1) { } D follows C++'s construct for initializing a variable in control blocks. The only exception I think is for switch. switch(int val = expr()) // ok in C++, not ok in D { }
Jan 29
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
On Tuesday, 29 January 2019 at 11:52:40 UTC, Andrei Alexandrescu 
wrote:
 Where should the temporary go?
Doesn't D already specify allocation and lifetime of temporaries? AIU the DIP doesn't invent the notion of a temporary.
Jan 30
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 1/30/19 3:34 AM, Kagamin wrote:
 On Tuesday, 29 January 2019 at 11:52:40 UTC, Andrei Alexandrescu wrote:
 Where should the temporary go?
Doesn't D already specify allocation and lifetime of temporaries? AIU the DIP doesn't invent the notion of a temporary.
My bad, I overloaded the term "temporary". I meant the variable inserted by the lowering.
Jan 30
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/29/19 6:52 AM, Andrei Alexandrescu wrote:
 While writing this example:
 
 int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
 if (alloc.reallocate(a, 200 * int.sizeof))
 {
      assert(a.length == 200);
 }
 
 =====>
 
 int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
 void[] __temp0 = a;
 if (alloc.reallocate(__temp0, 200 * int.sizeof)
 {
      assert(a.length == 200);
 }
 
 I noticed a problem - the lowering as informally described in DIP 1016 
 makes it difficult to figure how function calls present in control 
 statements like if, while, etc. should behave. Where should the 
 temporary go? An expression-based lowering clarifies everything. A 
 statement-based lowering would need to work on a case basis for all 
 statements involving expressions.
I don't think it's very difficult or confusing. Any rvalue in any expression that requires ref should be implicitly declared before the statement that contains the expression, and include a new scope: <statement involving rvalues r1, r2, r3, ... rN> ----> { auto _tmpr1 = r1; auto _tmpr2 = r2; auto _tmpr3 = r3; ... auto _tmprN = rN; <statement with _tmpr1, _tmpr2, _tmpr3, ... _tmprN> } Essentially, nothing is different from existing semantics today, when rvalues are used and provides reference semantics (yes, it's possible, see tempCString). They live until the end of the statement. It's how this has to be. It can't be expression based. -Steve
Jan 30
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/30/19 9:20 PM, Steven Schveighoffer wrote:

 Essentially, nothing is different from existing semantics today, when 
 rvalues are used and provides reference semantics (yes, it's possible, 
 see tempCString). They live until the end of the statement. It's how 
 this has to be. It can't be expression based.
I came up with this idea based on tempCString, but it doesn't work: struct RV(T) { T theThing; ref T getIt() { return theThing; } alias getIt this; } auto rv(T)(T t) { import std.algorithm : move; return RV!T(move(t)); } Of course, we'd need to suppress destructors here potentially. I tried to use it: import std.stdio; void foo(ref int i) {writeln("i is ", i);} void main() { foo(1.rv); } But it fails: Error: function testrvalue.foo(ref int i) is not callable using argument types (RV!int) cannot pass rvalue argument rv(1) of type RV!int to parameter ref int i If I manually execute the alias this, it works: foo(1.rv.getIt) So I don't get why it doesn't work. But if that was fixed, could be a potential workaround without requiring a DIP. -Steve
Jan 30
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 31 January 2019 at 02:29:47 UTC, Steven 
Schveighoffer wrote:
 I came up with this idea based on tempCString, but it doesn't 
 work:

 So I don't get why it doesn't work. But if that was fixed, 
 could be a potential workaround without requiring a DIP.
Thats nice! But it doesn't fix the problem that in generic code you don't know without checking if you need to do that. Also the template bloat.
Jan 30
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/30/19 10:03 PM, Nicholas Wilson wrote:
 On Thursday, 31 January 2019 at 02:29:47 UTC, Steven Schveighoffer wrote:
 I came up with this idea based on tempCString, but it doesn't work:

 So I don't get why it doesn't work. But if that was fixed, could be a 
 potential workaround without requiring a DIP.
Thats nice! But it doesn't fix the problem that in generic code you don't know without checking if you need to do that. Also the template bloat.
Yeah, it could do this too: auto ref rv(T)(auto ref T t) { static if(__traits(isRef, t)) return t; else /* do the other stuff */ } But yes, template bloat. Plus having to put rv on everything... would suck. The DIP to me seems like it should be good with the clarification of not applying to lvalue -> rvalue auto translations. -Steve
Jan 30