3 ms·

I didn't quite understand that point, can you rephrase? I mean, yeah, things like specs for computer languages do define a space for ambiguity, but that space i

by rhelz 3y ago

I didn't quite understand that point, can you rephrase? I mean, yeah, things like specs for computer languages do define a space for ambiguity, but that space is ambiguous just the same.

jiggawatts 3y ago
Let's say you wrote this code: a = 2 * b + c * d; writeToDisk(a) e = b + b - a; sendToNetwork(e) Naively, you would expect the compiler to emit CPU instructions that perform the computations left-to-right, top-to-bottom. In pseudocode assembly: mul 2, b -> a mul c, d -> reg1 add a, reg1 -> a push a call writeToDisk mov b -> reg1 add b, reg1 -> reg1 sub a, reg -> e push e call sendToNetwork The externally observable effects may be considered to be the function calls. If you're dealing with I/O devices then it would be some similar specific hardware event such as writing to a GPIO register. It should be immediately obvious that the compiler can compute 2*b just once, cache it in a register, and use it to compute both 'a' and 'e', even though the formulas are different and interspersed with function calls. Similarly, it can noticed that e has a 2b-2b in its overall formula and hence eliminate some computations entirely. As long as the inputs to the functions don't change and the order of their calls aren't modified, "all is fine" and the compiler is free to do this. In fact, modern compilers can completely eliminate function calls, inlining them if they perform pure computations or have no side-effects! This is done to such a point that it makes benchmarking challenging: merely timing some computations will often take 0 time unless the result of the computation is written to the console or some similarly externally-visible destination. Compilers are allowed to this even for abstractions like virtual functions or interfaces. The JVM does this regularly. If it notices there's only a single implementation of an interface, it'll inline it, possibly eliminating the call entirely if it turns out to be a no-op.
- rhelz 3y ago
  Ok, thanks for clarifying. But again, we are so used to dealing with ambiguity that we don't even notice it. It looks like the inputs/outputs are really nailed down....but still, it is ambiguous in countless ways. For example, you can type the input/output to these functions in any font or size you want. You don't have to use ASCII. The results on the screen can be glowing green phosphorus, red phosphorus, or a glorious retina display. etc etc. Wherever the specs end, the ambiguity begins.

by rhelz 3y ago

I didn't quite understand that point, can you rephrase? I mean, yeah, things like specs for computer languages do define a space for ambiguity, but that space is ambiguous just the same.

jiggawatts 3y ago

Let's say you wrote this code: a = 2 * b + c * d; writeToDisk(a) e = b + b - a; sendToNetwork(e) Naively, you would expect the compiler to emit CPU instructions that perform the computations left-to-right, top-to-bottom. In pseudocode assembly: mul 2, b -> a mul c, d -> reg1 add a, reg1 -> a push a call writeToDisk mov b -> reg1 add b, reg1 -> reg1 sub a, reg -> e push e call sendToNetwork The externally observable effects may be considered to be the function calls. If you're dealing with I/O devices then it would be some similar specific hardware event such as writing to a GPIO register. It should be immediately obvious that the compiler can compute 2*b just once, cache it in a register, and use it to compute both 'a' and 'e', even though the formulas are different and interspersed with function calls. Similarly, it can noticed that e has a 2b-2b in its overall formula and hence eliminate some computations entirely. As long as the inputs to the functions don't change and the order of their calls aren't modified, "all is fine" and the compiler is free to do this. In fact, modern compilers can completely eliminate function calls, inlining them if they perform pure computations or have no side-effects! This is done to such a point that it makes benchmarking challenging: merely timing some computations will often take 0 time unless the result of the computation is written to the console or some similarly externally-visible destination. Compilers are allowed to this even for abstractions like virtual functions or interfaces. The JVM does this regularly. If it notices there's only a single implementation of an interface, it'll inline it, possibly eliminating the call entirely if it turns out to be a no-op.

rhelz 3y ago
Ok, thanks for clarifying. But again, we are so used to dealing with ambiguity that we don't even notice it. It looks like the inputs/outputs are really nailed down....but still, it is ambiguous in countless ways. For example, you can type the input/output to these functions in any font or size you want. You don't have to use ASCII. The results on the screen can be glowing green phosphorus, red phosphorus, or a glorious retina display. etc etc. Wherever the specs end, the ambiguity begins.