[ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list ]
On Apr 23, 2013, at 12:03 PM, "Mark Janssen" <[email protected]<mailto:[email protected]>> wrote: But there are no details left out. Neither the computer nor compiler "fills in the gaps". What computing devices are you talking about? At every step, at the various levels of abstraction, from the high-level source code, to the the binary executable, there is a complete and detailed "transformation" logic. It will compile down to the same machine code *every* time, if it's working properly. Are you claiming, then, that all those fancy optimization flags I can pass to my C compiler don't actually do anything? Or that (say) -fomit-frame-pointer is unfaithful to the "complete and detailed transformation logic"? Better file a bug report. I well aware of compiler flags and was not implying at all that they don't do anything. What I was saying is that the compilers output is deterministic. If you use the same flags and the same source, you will get the same output -- unless you're suggesting some *magic happens here* event. So you meant to say that given a source program P, a compiler K, and a set of compiler options O, K executed with flags O will produce the same object/target code from P every time, if K is a correct compiler. I'm not so sure that's true -- smarter people than me have used genetic algorithms to determine more effective combinations/orderings of optimization phases, for example (see [1]). But in any case, you would admit that there are *multiple* target programs--call that set T(P)--that a compiler may emit from the same source program and still be correct. P determines T(P), but usually |T(P)| > 1. Therefore I do not think it is so fuzzy-headed to call P a specification. It's not the word I would use in everyday speech, but I thought you were the one who wanted to shake up the terminology of the field! ;) Adam [1] http://www.cs.rice.edu/~keith/Promo/LACSI2001.pdf.gz
