4 ms·

"User" refers to someone writing code in the programming language---someone "using" the compiler. It's not some project-management-y jargon. ----- Extending e

by dbaupp 8y ago

"User" refers to someone writing code in the programming language---someone "using" the compiler. It's not some project-management-y jargon. ----- Extending expressiveness vs sugar is fundamentally a property of the high level language, not the mid-level IR. It happens that talking about a mid-level IR is sometimes a nice way to "prove" that something is new or sugar. As the parent said, the programmer using the compiler only truly cares about the high-level language when writing code. They may dip into the mid-level for optimising their code etc., but they won't write it directly: to a non-compiler author, IRs are implementation details of the programming languages that happen give insight into how some detail of the language works or how a particular piece of code is optimised. To hammer home this point: if there's some major change required/desired in the high-level language, the current details of the mid-level language shouldn't affect the overall design. The mid-level IR can change to accommodate the desired surface behaviour.

Ericson2314 8y ago
- New program writers (more writing) - Old program maintainers (more reading) - Language implementers You leave out the 3rd and conflate the second. Others have conceive of PLs as some sort of bargain between human and machine, or human and pure math. Either way, there's multiple interests at stake. Or, even simpler, what if Rust becomes way harder to learn, but mastery gives one correspondingly way more productivity? Is that a fair trade in your eyes? (I do not believe in practice it will become way harder to learn, but I accept the situation I describe as fair and not a failure of Rust). ----- You may not write it directly, but you will still think about it. Again the IR of these good languages is like some platonic ideal that sacrifices concision of programs for concision of the language. It is not just an inplementation detail. Hell, if you insist on thinking that is just some crufty implementation detail, sure. But then let me show you how it's an abstraction that leaks badly, hahaha. - "Non lexical lifetimes" are probably the most anticipated Rust change lately (see rest of thread). But crucially, they are lexical at the level of MIR. The easiest way to precisely define them is desugar to an explicit control flow language. Otherwise you are forced to look at the a combinatorial explosion of surface-level constructs, or just handwave based in the intuition of control flow. - https://github.com/thepowersgang/mrustc/tree/master/src/mir https://github.com/thepowersgang/mrustc/tree/master/src/mir this is the alternative Rust implementation's MIR. It's pretty close to the same thing! (Not so with LLVM IR and GCC's RTL.) If mrustc gets to implementing NLLs, it will probably get even closer. - mrustc does not implement old borrow checking probably because it's sort of an arbitrary spec against the surface syntax. Surface syntax is much more boilerplate to go through all the cases, and while old lifetimes may have a simple enough rough intuition, they are very arbitrary when considered precisely. And yes, the core language can change underneath the hood, but this is highly unlikely in practice. GHC's core has certainly changed, but this is evolution more than revolution. I think the heart of what I'm saying is two things: 1. Formal reasoning is the only way to constrain complexity. Humans alone inevitably don't fully graps the entire thing (it's just too big!), and even when they do don't have identical mental models. The results is always contradictory design if any change at all is permitted. 2. Human PLs have lots of conveniences and other fluff (yes, even Scheme, Nix, or your other favorite minimalist language), so the only efficient way to reason about them formally is by desugaring to a core language.
- dbaupp 8y ago
  Language implementors are a very special case. Their effort is O(1) while the other two are O(amount of code in the language). In any case, I don't see what your point is. --- I think you're conflating things too: NLL is defined in terms of a CFG, which happens to be MIR at the moment, but if the current MIR is insufficient for some task, it can still be fundamentally changed, with the NLL semantics handled specially, e.g. with a multi-step lowering, like HIR in Rustc. The mid-level IRs chosen for a compiler are in service of the high-level language and its tools (like formal/static analysis), not the other way around. In fact, a static analysis or formal reasoning tool likely needs more information than fits into a compiler/optimisation-focused IR. (You see this even with LLVM IR vs MIR and SIL etc: LLVM IR can't hold enough info for the front-end to do everything.)

by dbaupp 8y ago

Ericson2314 8y ago

- New program writers (more writing) - Old program maintainers (more reading) - Language implementers You leave out the 3rd and conflate the second. Others have conceive of PLs as some sort of bargain between human and machine, or human and pure math. Either way, there's multiple interests at stake. Or, even simpler, what if Rust becomes way harder to learn, but mastery gives one correspondingly way more productivity? Is that a fair trade in your eyes? (I do not believe in practice it will become way harder to learn, but I accept the situation I describe as fair and not a failure of Rust). ----- You may not write it directly, but you will still think about it. Again the IR of these good languages is like some platonic ideal that sacrifices concision of programs for concision of the language. It is not just an inplementation detail. Hell, if you insist on thinking that is just some crufty implementation detail, sure. But then let me show you how it's an abstraction that leaks badly, hahaha. - "Non lexical lifetimes" are probably the most anticipated Rust change lately (see rest of thread). But crucially, they are lexical at the level of MIR. The easiest way to precisely define them is desugar to an explicit control flow language. Otherwise you are forced to look at the a combinatorial explosion of surface-level constructs, or just handwave based in the intuition of control flow. - https://github.com/thepowersgang/mrustc/tree/master/src/mir https://github.com/thepowersgang/mrustc/tree/master/src/mir this is the alternative Rust implementation's MIR. It's pretty close to the same thing! (Not so with LLVM IR and GCC's RTL.) If mrustc gets to implementing NLLs, it will probably get even closer. - mrustc does not implement old borrow checking probably because it's sort of an arbitrary spec against the surface syntax. Surface syntax is much more boilerplate to go through all the cases, and while old lifetimes may have a simple enough rough intuition, they are very arbitrary when considered precisely. And yes, the core language can change underneath the hood, but this is highly unlikely in practice. GHC's core has certainly changed, but this is evolution more than revolution. I think the heart of what I'm saying is two things: 1. Formal reasoning is the only way to constrain complexity. Humans alone inevitably don't fully graps the entire thing (it's just too big!), and even when they do don't have identical mental models. The results is always contradictory design if any change at all is permitted. 2. Human PLs have lots of conveniences and other fluff (yes, even Scheme, Nix, or your other favorite minimalist language), so the only efficient way to reason about them formally is by desugaring to a core language.

dbaupp 8y ago
Language implementors are a very special case. Their effort is O(1) while the other two are O(amount of code in the language). In any case, I don't see what your point is. --- I think you're conflating things too: NLL is defined in terms of a CFG, which happens to be MIR at the moment, but if the current MIR is insufficient for some task, it can still be fundamentally changed, with the NLL semantics handled specially, e.g. with a multi-step lowering, like HIR in Rustc. The mid-level IRs chosen for a compiler are in service of the high-level language and its tools (like formal/static analysis), not the other way around. In fact, a static analysis or formal reasoning tool likely needs more information than fits into a compiler/optimisation-focused IR. (You see this even with LLVM IR vs MIR and SIL etc: LLVM IR can't hold enough info for the front-end to do everything.)