0
1

[–] rdnetto 0 points 1 point (+1|-0) ago 

The problem with that is that it largely precludes having multiple compilers. Not entirely, but it certainly makes things more difficult. A compiler cannot add a new optimization without waiting for a new version of the language standard to come out.

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).

This approach would not simplify the compiler. I am not sure how you got the idea that this would strip out all of the machinery for determining what optimizations to do when. But a simple counterexample to that claim: you wrap the entire program in @suggest(*) (or whatever) and you get classical behavior.

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.

I agree fully with the semantic gap between compilers and humans. My general point is this. We already have strongly typed languages, etc. We do not have a language that deals with things in this way. It may be worth exploring simply because it is a potential alternative.

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)

0
1

[–] NotSurvivingLife [S] 0 points 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).