Quite lengthy but very interesting mail! It took me a while to formulate a proper reply :)
> Feedback can be scarce, but don't let that stop you from submitting a > proposal. > Either way, can you keep me informed about any progress? I might wish to help > though that would probably be later in the cycle (got a lot queued up for > the comming months). Submitted :) The reviews are not too positive yet, my biggest efforts go into making my plan clear. If any progress, help will be very appreciable indeed. > Great that's exactly what I'm aiming at:) It's not just presenting the > results of static analysis in real-time, as I actually dislike most > kinds of it like finding memory leaks, to me that seems like an attempt > to make the computer do what it's really bad at (understanding the > code). I just want to give the programmer the fullest picture of the > situation but at the same time make it so it doesn't become noise that > interferes. More or less you can say the goal is "To provide feedback > that allows the user to extend his understanding of the program". That > mostly means giving access to all the information that can be > unambiguously concluded from the code by the computer. To what degree > we carry it and how much the compiler is involved is only a question of > practicality and performance. I quite agree for the most part, still there is a subtle nuance on which I want to argue: Do we really help the programmer by offering all the valuable information that is possible to infer? Ten years from now, would he/she be a better programmer if we had not let him/her strive to simulate the program in mind, or code a portion in assembly and finally learn about machine architecture? My point is to avoid creating an interface that "assists" of "helps" the programmer, as he/she might become dependent on it. This is just helping in the short term, and the only person who ever learns something is the one who actually creates the compiler. If a statement could sum my view, it would be that "the user improves through his/her use of the interface" (here the feedback messages). How does it make a difference in practice? I want to minimize the information given :) The reason I want to introduce feedback messages is that this particular information (the inner workings of compilers) is very hard to find in practice. I want to give a slight help to put the user on the rails, nothing more. > Perfect! However, how to do that so that it actually works seems a bit > complex. The first (practically unsolvable) issue is what actually > constitutes better code, as given two pieces one may be faster in some > cirtumstances while the other in different. But as I understand that's > not really what we're trying to tell the user, rather we want him to > explore for himself what's possible and what are the results and why > they are the way they are? I'm guessing this will unfortunately (or > fortunately) require him to actually see and undestand the intermediate > code, see how it changes after different optimizations, and see the > output assembly. Personally I really need/want that;) Though my end > target is a bit more to "broaden" the abstraction when programming > (both up and down), so not to just show what's happening with the code > but also allow the programmer to interact with it on that lower level. > LLVM seems like the perfect fit for that but I've got some gripes with > it, and that is still far away in the future. Excellent! Letting the user explore by himself sounds great, and seing the output assembly/IR besides is indeed a must. I like the idea that compilation is a cooperation between programmer and machine (as far as the programmer is inclined to help of course). It would also be nice to see compilation be split at Value range propagation, as one could verify it is properly computed, before proceeding into optimizations. > Unfortunately I only saw 36m of it as it broke and seeking doesn't work > on vimeo for me, so I'll watch the rest later. To me it touches on some > of the right issues/concepts but in slightly the wrong way, and it > completely ignores some issues. Agreed. (Only the first half of the video is relevant for the programming prototype) Thibault
