[TYPES] Declarative vs imperative
Procter, Adam M. (MU-Student)
adamprocter at mail.missouri.edu
Tue Apr 23 13:35:09 EDT 2013
On Apr 23, 2013, at 12:03 PM, "Mark Janssen" <dreamingforward at gmail.com<mailto:dreamingforward at gmail.com>> 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 ).
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! ;)
More information about the Types-list