| |
 | Posted by Timon Gehr
in reply to Walter Bright |  Permalink Reply |
|
Timon Gehr 
Posted in reply to Walter Bright
| On 2/29/24 05:17, Walter Bright wrote:
> On 2/28/2024 1:03 PM, Timon Gehr wrote:
>> No, the idea is that the compiler enforces that it is indeed the last use and produces a compile-time error message if it cannot prove that it is the case.
>
> DFA works with mathematical reliability (absent compiler bugs). The optimizer relies heavily on DFA; if DFA was unreliable the whole edifice will fall apart. Leave move vs copy to the compiler. The move vs copy/destroy choice is an optimization, and should be semantically thought of it that way.
>
>> Yes. It still holds that one may want to make sure that a value is really moved at a given point. Sometimes this matters. Anyway, this is by far not the most important point.
>
> If more language features are needed to work around bugs in the DFA, you've failed as a language designer/implementer. :-/
> ...
This is not about catching bugs in the DFA. This is about allowing a reader of the code to not have to execute the DFA in their head in order to see that something is the last use.
> Last use DFA can be implemented in a mathematically correct manner.
No, it is undecidable. You can only implement a sound approximation.
> The downside to DFA is it slows down the compiler, which concerns me in adding it to the front end semantics. I'm guessing is that's a reason why Rust has a reputation for slow compiles. (C++ doesn't have an excuse!)
> ...
Last-use analysis on a control-flow graph can be implemented in an efficient manner using strongly connected components. It is even easier to compute on a structured program. Rust has no goto.
>
>>> A nice feature of this is that the type of a variable can be changed on redeclaration. Note that Rust allows this.
>>
>> This is a relatively common idiom in languages that support moves. It is annoying if you have to invent a new name for each intermediate result.
>>
>> One use case would be type state:
>>
>> File!(FileState.flushed) file = open("file.txt");
>> File!(FileState.buffered) file = file.write("hello ");
>> File!(FileState.buffered) file = file.writeln("world!");
>> // file.close(); // compile time error
>> File!(FileState.flushed) file = file.flush();
>> file.close(); // moves "file"
>>
>> // file.write("hello"); // compile time error
>>
>> Assume you have some declarations like these and you want to comment out part of the statements. It would now be annoying to have to rename variables.
>>
>> I.e., you want to use the same name for different versions of the same thing, similarly to how you do not have to change the name of a variable when assigning to it.
>
> Interesting that you bring that up. I've been slowly leaning towards the "single assignment" style, where a variable is only assigned to once, when it is initialized. Sort of a "head const" thing. Some languages enforce this (can't remember which ones).
>
> I find it makes code more readable.
> ...
My example in fact follows that style. Each variable is a separate variable that is initialized once.
> I get the feeling that allowing not only the contents, but the type of the variable change after re-assignment makes for less coherent code.
> ...
This is not being proposed. Redeclaration after move is not the same as reassignment.
> I'm not sure why, but I find Rust code hard to read. Maybe that's part of it.
Plenty of unfamiliar things in Rust to throw you off.
> I like the O/B system so much I implemented it in D (@live), not only that, but have begun adopting it as my own coding style. And it looks sooo much nicer in D syntax!
> ...
@live, while sharing some concepts, is ultimately not even the same kind of thing.
>
>>> We already disallow shadowing declarations, and that has prevented a number of bugs at least in my own code (they're very difficult to spot with a visual check).
>>
>> The reason why shadowing is error prone is that multiple variables with overlapping lifetimes are in scope and the compiler arbitrarily picks one of them. This case is different, as only one variable of the same name exists at any given time. This is not error prone.
>
> I've made that error myself now and then, usually as a result of moving code lines about.
> ...
Well, you can always make an error by moving some code lines into a scope in which they do not fit, but in this case, if you accidentally redeclare a variable of a name that already exists, you get a compile-time error.
>> Requiring unique names is more error prone in this case, as you can accidentally copy an older version of a variable.
>
> I can't remember making that error :-/
> ...
Presumably you used in-place updates in cases where it would have been hard to keep track of different versions.
>
>> Anyway, this is not the most important thing, please do check out the points I initially included in my review. This point is just something I had forgotten to include.
>
> Of course. This was just an easy to respond to issue.
> ...
I do feel like the response was shot from the hip.
> But a caveat. I'm kinda swamped at the moment. I'm working on some cool stuff for the upcoming DConf.
Of course! :)
> I also wrote the Move/Copy/Forward DIP before I worked on the O/B system for D. The whole Move/Copy/Forward needs to be studied in the context of how it fits in with O/B. This is going to need some careful study.
Sure. (This was also one of the things I pointed out.)
|
