It's the kind of thing that might make sense if you understood it, but that's hardly going to help a newbie. I also have some real doubt whether it's actually accurate or helpful. For instance<p>"If an execution is represented by a curve showing the evolution of the vector x(t) of values of the input, state and output variables of the program as a function of the time t, this concrete semantics can be represented by a set of curves (with continuous time for short):
x(t)"<p>To call these curves is just weird, and suggest this could be plotted on a two-dimensional graph is hugely misleading (And 'continuous time'???)<p>"The concrete semantics of a program is an "infinite" mathematical object which is not computable: it is not possible to write a program able to represent and to compute all possible executions of any program in all its possible execution environments"<p>Really? Let's determine if a program halts, that can't be trivial can it. Here's my program:<p><pre><code> HALT;
</code></pre>
"In formal methods the abstract semantics must be chosen as a superset of the concrete semantics since otherwise reasonings in the abstract might not be correct in the concrete"<p>By 'superset' I think he means a subset, or more restrictive, because otherwise you could have abstract semantics that allow <i>more</i> behaviour than the programming language. Or maybe it doesn't, but it's so bloody unclear that even I'm getting confused.<p>etc.<p>Abstract interpretation is an interest of mine (doesn't mean I know much about it though) and I think this post is a bloody mess.<p>I will look at the references he's provided and also at the other links people here have posted (thanks). I hope his books are better than his blog.<p>(Also AFAICT from the linked coures, this is circa 2005)