www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Discussion Thread: DIP 1034--Add a Bottom Type (reboot)--Final Review

reply Mike Parker <aldacron gmail.com> writes:
This is the discussion thread for the Final Review of DIP 1034, 
"Add a Bottom Type (reboot)":

https://github.com/dlang/DIPs/blob/b5bf9c4bed7afdae3bea1485093dbf2431bf72c7/DIPs/DIP1034.md

The review period will end at 11:59 PM ET on October 6, or when I 
make a post declaring it complete. Discussion in this thread may 
continue beyond that point.

Here in the discussion thread, you are free to discuss anything 
and everything related to the DIP. Express your support or 
opposition, debate alternatives, argue the merits, etc.

However, if you have any specific feedback on how to improve the 
proposal itself, then please post it in the feedback thread. The 
feedback thread will be the source for the review summary I write 
at the end of this review round. I will post a link to that 
thread immediately following this post. Just be sure to read and 
understand the Reviewer Guidelines before posting there:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

And my blog post on the difference between the Discussion and 
Feedback threads:

https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/

Please stay on topic here. I will delete posts that are 
completely off-topic.
Sep 22 2020
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 22 September 2020 at 12:14:50 UTC, Mike Parker wrote:


 However, if you have any specific feedback on how to improve 
 the proposal itself, then please post it in the feedback 
 thread. The feedback thread will be the source for the review 
 summary I write at the end of this review round. I will post a 
 link to that thread immediately following this post.


The feedback thread is here:

https://forum.dlang.org/post/ceicwtqcalmgiteudkjd forum.dlang.org
Sep 22 2020
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 22 September 2020 at 12:14:50 UTC, Mike Parker wrote:

 This is the discussion thread for the Final Review of DIP 1034, 
 "Add a Bottom Type (reboot)":

 https://github.com/dlang/DIPs/blob/b5bf9c4bed7afdae3bea1485093dbf2431bf72c7/DIPs/DIP1034.md


****PLEASE NOTE****
I apologize. The above is the wrong link. The correct link is 
here:

https://github.com/dlang/DIPs/blob/d492715d3c7ba2cee898930d261ab113c0a66ef9/DIPs/DIP1034.md
Sep 22 2020
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 22 September 2020 at 12:14:50 UTC, Mike Parker wrote:

 This is the discussion thread for the Final Review of DIP 1034, 
 "Add a Bottom Type (reboot)":

 https://github.com/dlang/DIPs/blob/b5bf9c4bed7afdae3bea1485093dbf2431bf72c7/DIPs/DIP1034.md

 The review period will end at 11:59 PM ET on October 6, or when 
 I make a post declaring it complete. Discussion in this thread 
 may continue beyond that point.

 Here in the discussion thread, you are free to discuss anything 
 and everything related to the DIP. Express your support or 
 opposition, debate alternatives, argue the merits, etc.

 However, if you have any specific feedback on how to improve 
 the proposal itself, then please post it in the feedback 
 thread. The feedback thread will be the source for the review 
 summary I write at the end of this review round. I will post a 
 link to that thread immediately following this post. Just be 
 sure to read and understand the Reviewer Guidelines before 
 posting there:

 https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

 And my blog post on the difference between the Discussion and 
 Feedback threads:

 https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/

 Please stay on topic here. I will delete posts that are 
 completely off-topic.


I have one (very) general comment. Since we are talking about the 
halting problem, completeness etc. Since time is in essence the 
problem, would it be possible to annotate a function with a 
timeout (physical or virtual time) which leads to the bottom type 
if exceeded? This could in theory be very useful.
Sep 22 2020
parent reply Dennis <dkorpel gmail.com> writes:
On Tuesday, 22 September 2020 at 12:44:14 UTC, Imperatorn wrote:

 I have one (very) general comment. Since we are talking about 
 the halting problem, completeness etc. Since time is in essence 
 the problem, would it be possible to annotate a function with a 
 timeout (physical or virtual time) which leads to the bottom 
 type if exceeded? This could in theory be very useful.


I have trouble picturing what you're suggesting.
You mean something like this?

```
import std;
 timeout(500.msecs) int computeSum(int[] arr) {
     int result = 0;
     foreach(v; arr) result += v;
     return result;
}

void main(string[] args) {
     int result = computeSum(args[1..$].map!(to!int).array);

     // the program will now crash with `assert(0)` if computeSum
     // did not complete in under half a second?

     writeln(result); // otherwise print result
}
```

I don't see when that's ever useful or why you need a bottom type 
to do that.
Sep 22 2020
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 22 September 2020 at 15:22:21 UTC, Dennis wrote:

 On Tuesday, 22 September 2020 at 12:44:14 UTC, Imperatorn wrote:

 I have one (very) general comment. Since we are talking about 
 the halting problem, completeness etc. Since time is in 
 essence the problem, would it be possible to annotate a 
 function with a timeout (physical or virtual time) which leads 
 to the bottom type if exceeded? This could in theory be very 
 useful.


 I have trouble picturing what you're suggesting.
 You mean something like this?

 ```
 import std;
  timeout(500.msecs) int computeSum(int[] arr) {
     int result = 0;
     foreach(v; arr) result += v;
     return result;
 }

 void main(string[] args) {
     int result = computeSum(args[1..$].map!(to!int).array);

     // the program will now crash with `assert(0)` if computeSum
     // did not complete in under half a second?

     writeln(result); // otherwise print result
 }
 ```

 I don't see when that's ever useful or why you need a bottom 
 type to do that.


Well, what about determinism, reasoning about halting, real-time 
contexts, time sharing, functional safety, async/await control, 
FSM constraints, resource management,..., etc

Well, strictly not bottom type, but it could be related,like 
(pseudo-code)  timeout(500.msecs, doSomething(), return something)
Sep 22 2020
next sibling parent reply Dennis <dkorpel gmail.com> writes:
On Tuesday, 22 September 2020 at 17:46:07 UTC, Imperatorn wrote:

 Well, what about determinism, reasoning about halting, 
 real-time contexts, time sharing, functional safety, 
 async/await control, FSM constraints, resource management,..., 
 etc


I get why asynchronous execution and time-outs are useful, but 
why do you want a time-out that results in the entire program 
crashing? To me it looks like you'd want a function returning a 
Nullable!T which is null in case of a time out, instead of a 
`noreturn` function which is guaranteed to always fail.


 Well, strictly not bottom type, but it could be related,like 
 (pseudo-code)  timeout(500.msecs, doSomething(), return 
 something)


So does your proposal fit in this DIP?
Sep 22 2020
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 22 September 2020 at 21:13:04 UTC, Dennis wrote:

 On Tuesday, 22 September 2020 at 17:46:07 UTC, Imperatorn wrote:

 Well, what about determinism, reasoning about halting, 
 real-time contexts, time sharing, functional safety, 
 async/await control, FSM constraints, resource management,..., 
 etc


 I get why asynchronous execution and time-outs are useful, but 
 why do you want a time-out that results in the entire program 
 crashing? To me it looks like you'd want a function returning a 
 Nullable!T which is null in case of a time out, instead of a 
 `noreturn` function which is guaranteed to always fail.


 Well, strictly not bottom type, but it could be related,like 
 (pseudo-code)  timeout(500.msecs, doSomething(), return 
 something)


 So does your proposal fit in this DIP?


Hmm... I guess it should be a new DIP. It's related to this, but 
not enough.
Sep 22 2020
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 22 September 2020 at 17:46:07 UTC, Imperatorn wrote:

 Well, what about determinism, reasoning about halting, 
 real-time contexts, time sharing, functional safety, 
 async/await control, FSM constraints, resource management,..., 
 etc

 Well, strictly not bottom type, but it could be related,like 
 (pseudo-code)  timeout(500.msecs, doSomething(), return 
 something)


This kind of thing can (and should) be implemented as a library. 
There's no reason to make it part of the type system.
Sep 22 2020
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 22 September 2020 at 21:52:24 UTC, Paul Backus wrote:

 On Tuesday, 22 September 2020 at 17:46:07 UTC, Imperatorn wrote:

 Well, what about determinism, reasoning about halting, 
 real-time contexts, time sharing, functional safety, 
 async/await control, FSM constraints, resource management,..., 
 etc

 Well, strictly not bottom type, but it could be related,like 
 (pseudo-code)  timeout(500.msecs, doSomething(), return 
 something)


 This kind of thing can (and should) be implemented as a 
 library. There's no reason to make it part of the type system.


Yup
Sep 22 2020
prev sibling parent Max Haughton <maxhaton gmail.com> writes:
On Tuesday, 22 September 2020 at 21:52:24 UTC, Paul Backus wrote:

 On Tuesday, 22 September 2020 at 17:46:07 UTC, Imperatorn wrote:

 Well, what about determinism, reasoning about halting, 
 real-time contexts, time sharing, functional safety, 
 async/await control, FSM constraints, resource management,..., 
 etc

 Well, strictly not bottom type, but it could be related,like 
 (pseudo-code)  timeout(500.msecs, doSomething(), return 
 something)


 This kind of thing can (and should) be implemented as a 
 library. There's no reason to make it part of the type system.


It would also some baggage to the standard (i.e. D assumes more 
things than some languages in its standard), not all machines 
would have the mechanism to implement it.

One thing this construction would require which I would quite 
like (although I can't quite see how it would be done cleanly) is 
some way of a UDA "knowing" what it is attached to i.e. currently 
 attr void func() {} can only do work if something looks from the 
top down at the scope it's in. There's probably a DIP in it 
somewhere but doing it nicely would need to be thought out 
properly.
Sep 23 2020
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
Continuing discussion from feedback thread:

On 9/22/20 11:08 AM, Dennis wrote:

 On Tuesday, 22 September 2020 at 14:16:19 UTC, Steven Schveighoffer wrote:

 ```
 int x;
 int bar();
 auto foo() {
     cast(noreturn) (x = bar()); // same as {x = bar(); assert(0);}
 }
 ```

 This is odd, and I'm not understanding the reason for the cast if you 
 aren't assigning.


 
 This code has no reason, it's just an example of the rewrite that 
 happens with `cast(noreturn)`. It could actually be useful in generic 
 code, or when you are using a function that is noreturn but does not 
 have the correct return type.
 ```
 // someone else's code
 void panic(string msg);
 
 // your code:
 auto f = () => cast(noreturn) panic("error");
 ```


The difference in the second example (which makes sense to me) is that 
you are returning the noreturn value.

If the first example said:

```
return cast(noreturn) (x = bar());
```

Then I understand. I thought the code was making an explicit point that 
not using the casted result still results in an assert(0).


 

 Also, earlier you say that you can declare a noreturn variable, but as 
 long as you don't use it, you don't generate the assert 0. Is this 
 example a contradiction of that?


 
 I don't think so, the example does not declare a local variable. I could 
 rewrite it to this:
 
 ```
 import std;
 int x;
 int bar();
 auto foo() {
      noreturn y; // no assert here yet
      writeln("this will get printed");
      y = cast(noreturn) (x = bar());
      // here it results in assert(0)
 }
 ```
 
 The reason for this is argued by Johannes Loher here:
 https://forum.dlang.org/post/r8v8tt$14fk$1 digitalmars.com
 

 ```
 /* 6 */ !(is(T == function)) || is(noreturn* : T)
 /* 7 */ !(is(T == delegate)) || is(noreturn* : T)
 ```

 What are these trying to say? I think these rules need some 
 clarification or rewriting


 
 In formal logic, "(not p) or q" is equivalent to "if p then q",


OK, I see what you are trying to do. The parentheses make it hard to see 
what it's trying to say. A comment or more specific explanation may help.

BTW, is(T == function) only works on actual function types, not function 
pointers. I think you meant function pointers.

-Steve
Sep 22 2020
parent James Lu <jamtlu gmail.com> writes:
On Tuesday, 22 September 2020 at 15:46:39 UTC, Steven 
Schveighoffer wrote:

 BTW, is(T == function) only works on actual function types, not 
 function pointers. I think you meant function pointers.

 -Steve


Pointing this detail out kindly is a good behavior. In the 
python-ideas mailing list, too often the attitude is "Your one 
detail is wrong therefore I will ignore and reject your entire 
proposal."
Sep 22 2020