5 ms·

No, a pure function taking the original source code as the only argument.

andrewflnr 9y ago
Exactly. There's no reason a compiler should take any input but the source (maybe some config) nor have any output but the translated code. There's no dependence on running on a particular piece of hardware in this equation. Just run the codegen for platform Y on platform X.
- coldtea 9y ago
  Wouldn't it need to link to native libraries, and thus require you to have all those around too?
  - andrewflnr 9y ago
    Sure, I guess in the 10,000 foot view those look like source code :). But there's no fundamental reason you can't have libraries for platform X merely present on a platform Y system, it's just inconvenient today. That's the point I'm really trying to get at.
eat_veggies 9y ago
I'll admit I don't know a whole lot about compilers but don't most of them do optimizations and other changes based on the CPU like its architecture, cache size, and instruction set? That may be what GP is getting at. Stuff like LLVM, and emscripten exist though so it's probably not as big of a deal as they say.
- andrewflnr 9y ago
  Sure, based on the target CPU. But there's no fundamental reason I can't do all those optimizations for, say, x86 in a compiler that happens to be running on an Arm CPU. As far as the compiler is concerned it's all just data that gets stuffed in files, just like any other software.
  - infogulch 9y ago
    The super-easy cross compilation in go is one of the best parts. Every install comes with the capacity to compile to every go target with no differences in input except setting it by name. This is really something more languages should strive for.
    - kibwen 9y ago
      > This is really something more languages should strive for. Most languages these days obviate cross-compilation in the first place by being interpreted. Of the languages that remain, the natively-compiled ones, most haven't gone to Go's lengths of writing a custom libc, which is emphatically not recommended for both Windows and Mac (the syscall interfaces aren't stable, and this has broken Go code in the past: https://github.com/golang/go/issues/16272 https://github.com/golang/go/issues/16272 ). And gc, the primary Go compiler and the one with out-of-the-box cross-compilation, supports relatively few platforms (I count 11, whereas rustc looks like it supports 50-70 platforms). You can use gccgo to get more platforms, but AFAICT gccgo's cross-compilation story isn't nearly as nice: https://github.com/golang/go/wiki/GccgoCrossCompilation https://github.com/golang/go/wiki/GccgoCrossCompilation . For Rust, cross-compilation looks like this: 1. Install the libc for the target system, and, if necessary, a compatible linker. 2. Run `rustup target add foo` where "foo" is one of the target triples on https://forge.rust-lang.org/platform-support.html https://forge.rust-lang.org/platform-support.html 3. Add the target triple to your Cargo.toml. Which isn't too shabby. You can read more about it here: https://github.com/japaric/rust-cross https://github.com/japaric/rust-cross
  - falcolas 9y ago
    Well, it's not just data - it's also frequently pointers or labels to code in dynamically imported libraries; things which can't always be calculated without the exact library being used on hand.
    - andrewflnr 9y ago
      Dynamic libraries are also made of data. See also my response to coldtea here: https://news.ycombinator.com/item?id=15310255 https://news.ycombinator.com/item?id=15310255
kibwen 9y ago
Be careful, let's not forget the lesson of Ken Thompson's Reflections on Trusting Trust. It's more accurate to say that compilation is a function that takes two arguments: the source code, and the compiler itself; this is how trusting-trust attacks propagate despite total absence from the source code.
- hasenj 9y ago
  And even if you could manually verify the binary output of a compiler and prove it correct, you still don't know that the CPU itself is not malicious.
- weberc2 9y ago
  You're being pedantic, but your pedantry is incorrect, so allow me to be pedantic in correcting you :p. The output of all pure functions depends on the function and its inputs; this isn't more true for compilers than, say, addition. The problem with Trusting Trust is that the function isn't practically inspectable, not that the function is impure. A trusting trust compiler is still pure.
  - falcolas 9y ago
    A functionally pure compiler would always provide the same output for the given source code. The challenges in creating repeatable builds of highly popular open source projects shows that the average compiler is anything but functionally pure. The global state of the system running the compiler has a huge impact on the output of the compiler.
    - weberc2 9y ago
      I agree, but that's irrelevant to the Trusting Trust topic.
- alphaalpha101 9y ago
  That's like saying any function is a function from its argument and itself to its output i.e. rather silly.
__david__ 9y ago
Incidentally, this is the principle that ccache[1] operates on. [1] https://ccache.samba.org/ https://ccache.samba.org/

Exactly. There's no reason a compiler should take any input but the source (maybe some config) nor have any output but the translated code. There's no dependence on running on a particular piece of hardware in this equation. Just run the codegen for platform Y on platform X.

coldtea 9y ago
Wouldn't it need to link to native libraries, and thus require you to have all those around too?
- andrewflnr 9y ago
  Sure, I guess in the 10,000 foot view those look like source code :). But there's no fundamental reason you can't have libraries for platform X merely present on a platform Y system, it's just inconvenient today. That's the point I'm really trying to get at.

eat_veggies 9y ago

I'll admit I don't know a whole lot about compilers but don't most of them do optimizations and other changes based on the CPU like its architecture, cache size, and instruction set? That may be what GP is getting at. Stuff like LLVM, and emscripten exist though so it's probably not as big of a deal as they say.

andrewflnr 9y ago
Sure, based on the target CPU. But there's no fundamental reason I can't do all those optimizations for, say, x86 in a compiler that happens to be running on an Arm CPU. As far as the compiler is concerned it's all just data that gets stuffed in files, just like any other software.
- infogulch 9y ago
  The super-easy cross compilation in go is one of the best parts. Every install comes with the capacity to compile to every go target with no differences in input except setting it by name. This is really something more languages should strive for.
  - kibwen 9y ago
    > This is really something more languages should strive for. Most languages these days obviate cross-compilation in the first place by being interpreted. Of the languages that remain, the natively-compiled ones, most haven't gone to Go's lengths of writing a custom libc, which is emphatically not recommended for both Windows and Mac (the syscall interfaces aren't stable, and this has broken Go code in the past: https://github.com/golang/go/issues/16272 https://github.com/golang/go/issues/16272 ). And gc, the primary Go compiler and the one with out-of-the-box cross-compilation, supports relatively few platforms (I count 11, whereas rustc looks like it supports 50-70 platforms). You can use gccgo to get more platforms, but AFAICT gccgo's cross-compilation story isn't nearly as nice: https://github.com/golang/go/wiki/GccgoCrossCompilation https://github.com/golang/go/wiki/GccgoCrossCompilation . For Rust, cross-compilation looks like this: 1. Install the libc for the target system, and, if necessary, a compatible linker. 2. Run `rustup target add foo` where "foo" is one of the target triples on https://forge.rust-lang.org/platform-support.html https://forge.rust-lang.org/platform-support.html 3. Add the target triple to your Cargo.toml. Which isn't too shabby. You can read more about it here: https://github.com/japaric/rust-cross https://github.com/japaric/rust-cross
- falcolas 9y ago
  Well, it's not just data - it's also frequently pointers or labels to code in dynamically imported libraries; things which can't always be calculated without the exact library being used on hand.
  - andrewflnr 9y ago
    Dynamic libraries are also made of data. See also my response to coldtea here: https://news.ycombinator.com/item?id=15310255 https://news.ycombinator.com/item?id=15310255

kibwen 9y ago

Be careful, let's not forget the lesson of Ken Thompson's Reflections on Trusting Trust. It's more accurate to say that compilation is a function that takes two arguments: the source code, and the compiler itself; this is how trusting-trust attacks propagate despite total absence from the source code.

hasenj 9y ago
And even if you could manually verify the binary output of a compiler and prove it correct, you still don't know that the CPU itself is not malicious.
weberc2 9y ago
You're being pedantic, but your pedantry is incorrect, so allow me to be pedantic in correcting you :p. The output of all pure functions depends on the function and its inputs; this isn't more true for compilers than, say, addition. The problem with Trusting Trust is that the function isn't practically inspectable, not that the function is impure. A trusting trust compiler is still pure.
- falcolas 9y ago
  A functionally pure compiler would always provide the same output for the given source code. The challenges in creating repeatable builds of highly popular open source projects shows that the average compiler is anything but functionally pure. The global state of the system running the compiler has a huge impact on the output of the compiler.
  - weberc2 9y ago
    I agree, but that's irrelevant to the Trusting Trust topic.
alphaalpha101 9y ago
That's like saying any function is a function from its argument and itself to its output i.e. rather silly.

__david__ 9y ago

Incidentally, this is the principle that ccache[1] operates on. [1] https://ccache.samba.org/ https://ccache.samba.org/