Semantics

Usually when defining a new programming language one will have to provide two items:
the syntax of the language and the semantics of the language. Now you might ask why do you need both things ? Isn't the syntax enough ?

Think about this: if I came to you and I give you a paper written in Klingon would you be able to read it ? (Star Trek hardcore fans would probably get a paper written in rural romanian :-)). In general the answer would be no. In order to read it you would need to know how to transform the Klingon phrases in English phrases (a language that you already know). You would need at least a Klingon/english dictionary. In order to do it properly you would also need to know the grammer rules of the Klingon language. The dictionay and the grammar rules are in fact a semantic of the klingon language with the english language as a target (one that the recipient knows!). In effect the semantic of a language will define the meaning of phrases written in that language. This is another reason why crypto works :-). When you get an encrypted message you really have no clue what is the meaning associated with that text you got. And you can deduce virtually zero information about the semantics starting from the text you have. The stupid cyphers usually have semantics embedded into the syntax or are too close to the actual target language (the one which is encrypted) and slip that info on carefull analysis.

You can define the semantics in more than one way (see here for a more detalied presentation of the formal semantics of programming languages). To put it short there are three big ways: translation, interpretation and using logical axioms. When you give a semantics using the translation method you actually writing the translation rules from the source langauge into a known target language (usually compiling C to ASM is doing something like this). When using the interpretation method you are effectively describing what it will happen for every source phrase with a target known system (usually assembler can be described like that). I really don't have a good idea of an example using the third approach so i will leave like that. But basically what it is happennig with the third approach is this: you can define axioms for every building block of the language and inference rules for every combinatorial building block of the language. The meaning of a phrase in the languages is the resulting meaning in the defined logic (probably XSLT is/can be defined using something similar).

That's it for today :-). See you next time.

Mihai