It occurred to me today that although I\'ve adopted and don\'t infrequently use the term \"semantics\" when referring to language elements and naming conventions, I don\'t have
It's the meaning of the language elements in terms of what they formally mean in terms of computation (usually, and this is the operational semantics). This means that it expresses what a term of your language effectively does assuming an underlying kind of model that depends on which semantic we are talking about.
As you can see from wikipedia page you mainly have 3 kinds of semantics:
+
: pops two elements from the stack and push the sum. This is NOT formal and it is NOT how you should really consider it, it's just to give you an idea). This is the most used one to describe semantics of "normal" programming languages. For example for Java you could have, for every possible term, a sequence of JVM instruction meant to be executed to model that term. Probably when you asked for the meaning of semantics this is the one you were looking for.+
that contains what is the semantic (effective meaning) of the termFrom this decription you understand that a semantic is something well defined inside a context, and you need a specified context otherwise you couldn't give you language a formal definition of what its terms do..
A definition cribbed from here is The semantics of a programming language describe the relationship between the syntax and the model of computation.. This is pretty much exactly what your inferred definition was. The sticking point, and what made your eyes glaze over is precisely defining the model of computation.
There are many different formal models of computation and each leads to a different form of semantics. Operational Semantics is probably closest to the way most people informally model the semantics, having each fragment of code run through an interpreter and changing the state of an abstract routine. This approach breaks down in many models where concurrency or nondeterminism, etc., so there are other sematics better suited to these situations.
From a perspective of the theory and practice of programming languages, language elements have semantics. Naming conventions don't. And semantics has nothing to do with 'fidelity' to anything, except perhaps that if an implementation is correct it is sometimes called "faithful to the semantics."
Beyond that it's hard to generalize because there are so many different styles of semantics.
There are other styles of semantics, called "operational semantics", where given a program, the semantics tells you how that program will be executed on an abstract machine (or in another variant, the semantics says not how the program will be executed but only what the result will be).
There is "axiomatic semantics" which is roughly about what facts you can prove about individiual programs. The axiomatic semantics is a collection of valid proof techniques. It's up to the implementation to ensure that all provable claims are true.
There is also "static semantics", by which is meant broadly any requirements imposed at compile time for the program to be considered "good" or "well formed". Stuff like "variables have to be defined before they are used" is static semantics. But mostly when people say static semantics they mean type checking.
Finally, it is possible to speak of the "semantics" of an abstract data type, a class, or an interface, among others. This usage are a good deal looser, but they boil down to a specification of what behaviors are permissible. I advise you to avoid the word "semantics" in this context and to use the word "contract" or "specification" instead. It will avoid confusing things.
Commentary: it's not always helpful to try to boil down a complex subject to one or two sentences. And when it comes to programming languages, don't look for good information on Wikipedia. The Wikipedians mean well, but too often they are complex, confusing, or just plain wrong.