I have a thought. This is dangerous, I know. Here's my thought:
A programming language where optimizations are feedback. In other words, a programming language where optimizations are explicit, and opt-in. With the compiler (or even runtime feedback) suggesting optimizations. Not implementing them behind your back, but merely suggesting them.
Why? In most programming languages, there's an interesting dilemma. Mainly, that a) you don't know what is actually running, b) that you cannot rely on optimizations, and c) sometimes optimizations are in fact pessimizations.
So, I suggest a programming language where optimizations are explicitly opted into and out of (hierarchically, with most specific scope overriding) by annotations (or something similar), either as a requirement or a suggestion. (For something like TCO, for instance, you may wish to require it. Whereas you may wish to only suggest that a loop be unrolled.)
Does it mean more typing? Does it mean that it takes more time to code? Not really - if that's really a concern just enable everything as a suggestion for the entire project. But most of the time you shouldn't do that, or do it sparingly.
But the advantage of this is that everything is explicit. You know what the compiler is actually doing, as opposed to what you hope you are thinking that you are trying to get the compiler to do (or not do!).
You can actually tell the compiler that no, in fact, that variable that's about to be freed must be zeroed first. Or that unrolling that loop is something that should be done regardless of if it looks good on the surface.
(This was all spurred by me trying to figure out if it's in fact possible to securely zero an array in portable C, and coming to the conclusion that you cannot actually do so. The compiler can and will optimize out things. And even things that it doesn't optimize now, it is allowed to optimize out later.)
view the rest of the comments →
[–] rdnetto 0 points 1 point 1 point (+1|-0) ago
You'll run into that in any language were optimizations are specified, since the optimizations available are dependent on the way the compiler is implemented. The only way to make optimizations explicit without specifying them as part of the language is to write assembly (or something like it).
I had a mental model where the optimizations and machine code generation were done by different tools, but when I tried to explain I realised they were just different layers of the compiler. My bad.
Agreed. Research languages are always fun to experiment with, even if they never get used for anything. I suspect the area you'd end up exploring here would be what structures are best annotated with optimizations - that is, whether to annotate imperative blocks of code (if statements, loops, etc.) or to annotate the values/variables themselves (which would enable a more functional approach). I guess you'd need both if you wanted to be able to disable all optimizations, but I'm having a hard time thinking of situations where something like TCO causes problems. (apart from debuggers and stack traces)
[–] NotSurvivingLife [S] 0 points 1 point 1 point (+1|-0) ago
TCO can and will cause problems with exceptions. In particular, the stack trace will be incomplete. It also turns some stack overflows (which can often be dealt with) into infinite loops (which are harder to deal with).
Something like how CSS is done - with vendor prefixes / namespacing that later gets dropped - would work well for this sort of thing. Not perfectly, but "good enough", I think.
I suspect that said annotations would be useful both for code and data (as for said, imperative versus functional).