Re: Chat with Stefan Koch about CTFE reimplementation
On Monday, 23 May 2016 at 16:32:30 UTC, deadalnix wrote: On Monday, 23 May 2016 at 15:57:42 UTC, rikki cattermole wrote: Hello! [...] Call me party pooper or something but this whole things seems to get way out of control. In order to asses the quality of the new design, one need to compare it to a baseline (aka the existing design) or one is basically going blind and unlikely to end up anywhere. There are obvious low hanging fruits in the existing design. For instance using a region allocator and blast it all after a CTFE run. It is like we have a car with square wheels, and you guys a reinventing a whole new car without even trying to maybe put round wheel on the existing one and see how it goes. Overall, that means you are embarking in an expensive project, with 0 visibility on the actual value provided. The maintainer of his own D frontend saying, "Let's not reinvent the car?" ;) You make a valid point, but part of the fun of open source is reinventing the wheel. Since that's what Stefan wants to do, let's hope he can get it done.
Re: Chat with Stefan Koch about CTFE reimplementation
On Monday, 23 May 2016 at 16:32:30 UTC, deadalnix wrote: It is like we have a car with square wheels, and you guys a reinventing a whole new car without even trying to maybe put round wheel on the existing one and see how it goes. I this particular model of car. The bolts of the wheels are on the inside. And you have to dismantle almost everything to change them.
Re: Chat with Stefan Koch about CTFE reimplementation
On Monday, 23 May 2016 at 16:32:30 UTC, deadalnix wrote: On Monday, 23 May 2016 at 15:57:42 UTC, rikki cattermole wrote: Hello! [...] Call me party pooper or something but this whole things seems to get way out of control. In order to asses the quality of the new design, one need to compare it to a baseline (aka the existing design) or one is basically going blind and unlikely to end up anywhere. There are obvious low hanging fruits in the existing design. For instance using a region allocator and blast it all after a CTFE run. It is like we have a car with square wheels, and you guys a reinventing a whole new car without even trying to maybe put round wheel on the existing one and see how it goes. Overall, that means you are embarking in an expensive project, with 0 visibility on the actual value provided. I get your point. However to stick with your car metaphor. We have a car with square wheels and a weak frame. As soon as round wheels enable it to go faster something else will give. Also I don't want a car. I want a rocket.
Re: Chat with Stefan Koch about CTFE reimplementation
On Monday, 23 May 2016 at 15:57:42 UTC, rikki cattermole wrote: Hello! [...] Call me party pooper or something but this whole things seems to get way out of control. In order to asses the quality of the new design, one need to compare it to a baseline (aka the existing design) or one is basically going blind and unlikely to end up anywhere. There are obvious low hanging fruits in the existing design. For instance using a region allocator and blast it all after a CTFE run. It is like we have a car with square wheels, and you guys a reinventing a whole new car without even trying to maybe put round wheel on the existing one and see how it goes. Overall, that means you are embarking in an expensive project, with 0 visibility on the actual value provided.
Chat with Stefan Koch about CTFE reimplementation
Hello! So on today's stream[0] I had a chat with Stefan and worked through a few problems regarding reimplementation of dmd's CTFE. So a TLDR for those who do not wish to watch the video. - ddmd.dinterpret will have only two public free-functions (ctfeInterpret and ctfeInterpretForpragmaMsg). - For this, CompiledCtfeFunction struct will be removed from FuncDeclaration (.ctfeCode). The suggested fix is by using a hash table in dinterpret. - extern (C++) Expression getValue(VarDeclaration vd). Will no longer be used as is in ddmd.ctfeexpr. - printCtfePerformanceStats will be deleted altogether. - Everything else is essentially (or will be) private. Please note that these are not final, it is just the solutions we found during the stream in isolating dinterpret to itself. The benefits to this is of course, the implementation of CTFE will not publically expose its inner workings. Meaning if it is desired, it can be concurrent or JIT'd. Finally a question from Stefan, how much does dinterpret actually need the backend for transiently? We know from looking that it doesn't appear to use it in at least 2 degrees of separation. Please note that I do not intend for this video to get posted on Reddit since its about dmds internals (and not very important). [0] https://www.livecoding.tv/alphaglosined/videos/radD5-talking-with-stefan-koch-about-dmd
