Semantics Discussion

Continued from ValueExistenceProofTwo:

{It's self-evident that constructs like "if (p) {} else {}" and "while (p) {}" have the same semantics in all popular imperative programming languages. That is sufficient to demonstrate commonality.}

I'm sorry, it's not obvious to me. Perhaps CommonSenseIsAnIllusion is applicable. Every head is different. I might use the same thought processes between similar languages, but that is not a necessity, nor do other humans necessarily use the same thought processes that I do. What keeps somebody from using Head Model A for say End-X style block (VB-like) languages and Head Model B for curly-brace-style languages? (PHP) Granted, such may be poor reuse of mental models, but that's a "design quality" issue, not an absolute requirement.

{If it's not obvious that constructs like "if (p) {} else {}" and "while (p) {}" have the same semantics in all popular imperative programming languages, then there should be an example of a popular imperative programming language where "if (p) {} else {}" or "while (p) {}" differs semantically from other popular imperative programming languages. What is that language, and how do "if (p) {} else {}" or "while (p) {}" differ semantically in that language?}

But it may be tradition (historical patterns) that say the End-X block style is interpreted similarly (processed similarly) or matches the curly-brace style. In other words, it is "ingrained" that language patterns such as "while...end while" can be interpreted as (mentally replaced by) "while {...}" There are different mental techniques to arrive at similar answers and thus different mental techniques to apply these cross-substitutions in the mind when needed. For example, person A may think in End-X style and person B think in curly-brace style. When person A sees curly braces, in their mind they will translate to End-X style; and vise versa for person B. To me they are using different semantics in their head, but can cross-translate as needed. Person C may use a mental Tinker-Toy model to "run code" in their head, and translate both End-X and curly-brace style into their tinker-toy model. Person C is not using the same semantics as person A and B, but can translate the syntax to his/her preferred semantic model. I'm not sure there is an objective or clear commonality between all 3 people's head models. X being able to be translated into Y does not necessarily mean X and Y have "common semantics".

{What does this have to do with "head models"? "Different semantics in their head" is irrelevant, and treating "End-X block style" as different from "the curly-brace style" is about syntax, not semantics. Programming language semantics are about how language statements are computed, not what sequences of characters (or whatever) are used to specify them. I know of no language where "if (p) {} else {}" or "IF p THEN ... ELSE ... END IF" does anything but evaluate boolean expression 'p' to determine which of two code blocks is executed. I know of no language where "while (p) {}" or "WHILE p BEGIN ... END WHILE" does anything but repeatedly execute the code block as long as the boolean expression 'p' evaluates to 'true'. You can choose whatever words or formalisms you like to express it or describe it, but what happens in terms of the language on the machine -- i.e., the semantics -- are the same.}

We don't know if it's about semantics or syntax or both without x-ray-ing heads. Heads may be able to gleam a lot of info from JUST syntax patterns; enough to convert it into a personal arbitrary pet "semantic" model. A programmer may think in BrainFsck, and develop mental techniques to internally parse Php into BrainFsck in their head, and then "run" it as BrainFuck in their head. If their head is running BrainFsck, they are NOT processing Algol-style languages.

1. A BrainFsck interpreter does not "have" ("apply"?) Algol-style semantics, correct?

2. And we can write a translator that translates Php into BrainFsck via syntax rules, correct? (I'm assuming here syntax-based translation is not application of "semantics", but since "semantics" is vague, am not fully committing to it.)

3. And then we can run that translated version of code on a BrainFsck interpreter, correct?

4. But the BrainFsck interpreter is STILL NOT processing "Algol-style semantics", correct?

5. Thus, we don't need Algol-style semantics to run/emulate Algol-style code (such as Php), correct?

(Please reply below the list, using the numbers to reference statements.)

{We don't have to "xray heads" to distinguish syntax from semantics. In programming languages, syntax consists of rules -- typically expressed via a grammar -- that define what characters may appear where in order to form valid statements. Semantics describes what the language parts are, how they interact, and what they do at a language level. Semantics are what define that a statement like "a = foo() + b;" means -- and by "means", I mean (hah!) how language statements describe or use variables, assignment, functions, function invocation, addition, values, and so on. All of these things have to be defined, mapped to syntax, and rules created that specify how they interact. That's semantics. When we say, "the keyword 'while' is followed by a left parenthesis, an expression (itself a series of rules for assembling characters), a right parenthesis, a left curly brace, an arbitrary block of code (another set of character sequence rules), and finally a right curly brace", that's syntax. When we say that the syntax describes "a 'while' loop that executes the code block as long as the boolean expression is true", that's semantics.}

  Language A --> semanticsExtractor --> "blazz gim zerf"
  Language B --> semanticsExtractor --> "moof plet blanch"    
  Language C --> semanticsExtractor --> "uugnot zerf pleemp"
  write(isSemanticsEquiv("blazz gim zerf","moof plet blanch")); // result: "True" (A==B)
  write(isSemanticsEquiv("moof plet blanch","uugnot zerf pleemp")); // result: "True" (B==C)
  write(isSemanticsEquiv("blazz gim zerf", "uugnot zerf pleemp")); // result: "True" (A==C)
.

{How programmers interpret syntax, or semantics, is irrelevant. Semantics define what code is meant to do. How we understand a program to run has no effect on how it runs.}

{You can certainly translate a language 'a' having semantics 'x' into language 'b' having semantics 'y'.}

So you agree that at least in theory an interpreter can "run" language X withOUT using language X's "semantics"? (Via cross-translation.)

{You've misunderstood me. If you translate language X to language Y and execute language Y, you're not running language X. If you implement language X in language Y, then the semantics are language X, because language Y is not visible (it has its own semantics) to language X.}

Re: "If you translate language X to language Y and execute language Y, you're not running language X" -- Do you mean an interpreter for X or source code apps in X?

{I mean source code apps. Translating C# apps to Haskell will result in Haskell semantics.}

So is it safe to say that "semantics are being translated"?

{The semantics of the application may be changed. The semantics of the language(s) is(are) constant.}


I agree that an algorithm can be influenced by "semantics" (ideas, notions, concepts), but that is not the same as an algorithm "having" semantics "in" it. How do we objectively verify an algorithm "has" semantics "in" it, and how do we compare to know if algorithm A has equivalent semantics to algorithm B? -t

Algorithms don't have semantics, so your question is ill-formed. However, this quite clearly comes from the claim that semantics are implemented with algorithms. You can tell if implementations have the same semantics by comparing the effects of running them. (Note: the effects in question are limited to the ones the language in question specifies at the abstraction level specified by the language in question. Generally, we don't care if a particular bit is set or cleared. We just care whether or not the variable (however that got implemented) contains the value 5 of type integer (however that got implemented). BTW, I don't agree that algorithms are can be influenced by semantics.

How do we know exactly that "algorithms don't have semantics"? You say its "in" languages but not "in" algorithms. How does one check this in-ness?

One looks at the definitions. Semantics are the mapping of language structures to meanings. Algorithms aren't language structures. QED.

Sorry, I'm not following. This "mapping" happens in human heads, not in interpreters.

In humans, it happens in heads. In computers, it happens in interpreters and compilers. Programming languages map language structures to meanings in human heads, interpreters and compilers, because programming languages are understood by both humans and computers.

I still reject the idea that interpreters "see" or "contain" meaning directly. Meaning influenced their design, but influence is not equivalence.

Perhaps interpreters don't "see" or "contain" meaning the same way humans do -- we don't know how humans see or contain meaning, so we can't tell -- but we certainly know how interpreters "see" or "contain" meaning. Given human understanding of language semantics -- for example, how variables are meant to work, based on a language design specification or language reference manual -- we associate language structures with parts of the interpreter or compiler implementation. In a typical interpreter or compiler, this requires (in part) explicitly associating elements of the language grammar with actions that are to be performed by the interpreter or compiler when those elements are encountered whilst parsing the source code. That's how the meaning of a language is "seen" or "contained" by an interpreter or compiler.

Yes, that's "influenced by".

Yes, that's "influenced by", but it's also "implements". Both humans and computers "understand" the meaning of programming languages; perhaps in different ways, but sufficiently for all practical purposes.

I disagree that interpreters "understand" meanings. They process algorithms blindly. If there are "semantics" inside, it so far is not an objectively observable trait.

For all we know, human brains process algorithms blindly. "Understand" may be (and in the case of programming language interpreters and compilers, is) entirely mechanical. There's nothing that says "semantics", or meaning, requires human-style self-aware cognition.

We don't know what it requires because it's so ill-defined.

No, it's well-defined but abstract. We don't know what it requires in human brains because the human brain is not well-understood. We know exactly what it requires in interpreters and compilers because interpreter and compiler construction is well-understood. We know exactly how to turn the semantics of a programming language into specific actions to be performed by the interpreter or compiler when it interprets or compiles source-code. So, we say the interpreter or compiler implements the semantics of the language, or, in other (deliberately anthropomorphic) words, it "understands" the language.

But there are multiple ways to implement interpreters. Most are shaped by common conventions modeled after time-tested and road-tested ideas and tuned for machine efficiency on existing hardware. Future hardware or new interpreter ideas may change all that some day, or there may be interpreters built merely to predict and highlight certain concepts/features without concern for efficiency (sound familiar?). What you describe as "understand" above appears to be one of many possible paths to "understanding". Measuring understanding by current or popular implementation techniques does not produce the "canonical semantics" you claim/suggest exists. The "uniqueness problem" still persists. And who's to say that human programmers all run the same "ideas" in their head to predict code results? There's probably multiple "meaning" paths in human heads also. I already gave examples of different "school paper" techniques one can use to process expressions on paper. -t

There are multiple ways to implement interpreters, and there are perhaps multiple ways for us to understand the semantics of languages. However, independent of individual human (mis)interpretation, the semantics of all popular imperative programming languages -- based on language behaviour and various sources of language documentation -- are consistent to the point of being canonical. These are documented at the top of TypeSystemCategoriesInImperativeLanguages.

I'm skeptical it's "canonical". And if it were canonical, I'm skeptical TypeSystemCategoriesInImperativeLanguages is THE canon (except maybe among interpreter/compiler writers, per tradition or machine-centric tuning). I'd like better evidence. English rephrasing doesn't cut it, in part because such descriptions are not unique per target code snippet, and because much of English is vague or ambiguous. I agree there could be a "historical habit" of ways of thinking about or describing the processing of code, but it's hard to extract such information from developers beyond anecdotes. Further, the historical habit doesn't have to be universal. It may be shaped by machine efficiency concerns and/or just plain historical habit ("we always did it that way"). Please make clear what stance you are taking or talking about with regard to actual-as-is/historical canonization versus universal canonization (independent of human/Earth history/habits/hardware). I tend to partly agree with the WikiZen complaining about bias of the "Von Neumann habit" (CanProgrammingBeLiberatedFromTheVonNeumannStyle). Our thought processes may be shaped by it, and that's not necessarily a bad thing (our common reference "engines" may necessarily be some arbitrary common UsefulLie to aide in communication), but it may be possible that the real universal "canonical" semantics may look very different from the usual descriptions we give it (such as "move the results of expression evaluation on the right to the slot on the left"). Humans talk in terms of moving and copying parts or objects to and from slots or buckets (arguing over the names of these parts and buckets). But these are metaphors borrowed from our physical human world. Perhaps there's a quantum or many-worlds metaphor/semantics that is equally or more valid, for example. -t

You should be able to justify your scepticism by demonstrating at least one popular imperative programming language that deviates from others in terms of the semantics -- and, hence, the language behaviour -- of variable assignment, and/or function definition and invocation, and/or 'if' statements or 'while' loops. Furthermore, you should be able to demonstrate at least one popular imperative programming language that deviates from the explanations in TypeSystemCategoriesInImperativeLanguages.

As for a "quantum or many-world metaphor/semantics that is equally or more valid", I'd like to see it. Until then, I'll have to regard the chances that there are valid "quantum or many-world metaphor/semantics" as being roughly on par with "New Age" crystals being valid explanations for scientific phenomena. I.e., none at all. Of course, even if there are such semantics, that wouldn't mean the conventional semantics are suddenly invalid or no longer conventional.

Fine, use the Babbage-style scenario instead of a mechanical expression evaluator. A Babbage-like technician's "semantics" may be purely mechanical. The technician may "think mechanically" to describe or think about expression evaluation. You may decide to call a certain gear movement "assigning", but that's just an arbitrary label slapped on it. There's no current proof that it has/uses some some canonical "semantics" it shares with some other interpreter or reference semantics.

How some "Babbage-like technician" may misinterpret language semantics is irrelevant. The misunderstandings of individuals are no basis for anything. In my youth, a young friend of mine told me he believed, as a child, that trained ants ran up and down inside our limbs and pulled our skin and bones from the inside when we wanted to move. Obviously, no reasonable medical science would ever be based on some "ant theory" of musculature! Similarly, no consideration need be given to some odd "Babbage-like" gear-movement-assignment theory of programming language semantics.

I base my determination that there are common language semantics on (at least) two things: 1. Programming language reference manuals, which document language syntax and semantics; and 2. the run-time behaviour of programming languages. I note that any straightforward algorithm employing variables, variable assignment, expressions, functions and loops can be ported from one popular imperative programming language to another with only negligible tweaks to syntax. That, in itself, is a sound demonstration that there are canonical semantics common to all popular imperative programming languages.

Furthermore, any mediocre programmer can read a straightforward algorithm employing variables, variable assignment, expressions, functions and loops in any popular imperative programming language, with -- at most -- a quick primer on syntax differences. That is further demonstration that there are canonical semantics common to all popular imperative programming languages.

No no no, I didn't say the mechanical version is "wrong". It can properly model/predict typical math expressions (I/O profile-wise). It is not objectively "wrong".

It doesn't matter whether it's right or wrong. I know of no "mechanical version" in the literature. I know of no language reference -- and certainly not for any popular imperative programming language -- that describes a "mechanical version" of semantics.

And what you describe may be common syntactical elements/patterns, not necessarily "common semantics". One can see such syntax patterns, and translate such to their personal favorite head model, even a mechanical Babbage-like one, and produce the "right" answer.

Syntax only describes orderings and arrangements of symbols. The fact that similar syntax behaves identically when a program is executed is evidence of common semantics. What a programmer can see, what his or her "favorite head model" might be, is irrelevant.

Suppose a new programmer learns to program in JavaScript (JS) and gets a few years under their belt. Then they are asked to program in VB-Script (VBS). At first the different syntax throws them for a loop (no pun intended), but after a short while they mentally learn to translate VBS into JS back and forth in the mind (and learn rules of thumb to handle the differences in capabilities). They are not reading meaning directly from VBS, but translating it into JS in their mind. It's essentially "dumb" syntactical translation.

We can extrapolate this scenario into the mechanical view. Syntactical patterns could probably be mentally mapped to mechanical constructs (which are capable of producing the correct output). In fact "stack" comes from a mechanical idiom.

The fact that our hypothetical programmer can translate syntax, without having to translate semantics, is evidence of common semantics in the languages. It doesn't matter what's in the programmer's head.

Without a clear-cut way to measure and verify your description of "semantics", I cannot confirm nor deny your claim. And my colloquial interpretation of "semantics" is that it's something that only happens in human heads (and maybe AI machines). Your "in the machine" statement contradicts this. And as a reminder, semantics (ideas) may influence implementations, but that's not the same as "being in".

You can trivially verify my claim. Write the same simple program -- say, to find the first ten prime numbers -- in five different popular imperative programming languages. Make sure the implementations work. Show them to your colleagues and ask them to read the programs and tell you whether or not they think the programs do the same thing.

What does this prove exactly, and how? I only see it proving predictive capability of the human readers.

This proves that the same syntax has the same meaning in popular imperative programming languages.

Semantics exists every time you, say, assign an expression to a variable. The variable exists, and the expression exists, both in the interpreter environment and the source code. They do something, with measurable results in the program operation. They aren't syntactic, because the syntax can vary from language to language, yet "assign an expression to a variable" exists in every popular imperative programming language. That is semantics.

Re: "yet 'assign an expression to a variable' exists in...programming languages" -- Again, interpreters don't think, and don't think in English. You again appear to be anthropomorphizing interpreters or mentally projecting (imagining) your thought patterns into them.

Interpreters don't have to "think" for 'assign an expression to a variable' to exist in programming languages. Do you know any popular imperative programming language that doesn't implement 'assign an expression to a variable'?

They don't "run" your English. It's a silly question. You again appear to be anthropomorphizing interpreters or mentally projecting (imagining) your thought patterns into them.

Of course they don't "run" English. "Assign an expression to a variable" is the English we use to describe the language semantics, but "assign", "expression" and "variable" are all real language constructs regardless what we call them.

You are describing syntax elements. Even a non-AI machine can identify such parts (AKA parser).

No, syntax only describes the above as something like "<sequence of characters> <symbol> <sequence of characters> ( <symbol> <sequence of characters> [ '(' <blah blah blah> ')' ] )*". Syntax defines allowable arrangements of symbols that form valid sentences in a language. What those sentences mean to us humans -- such as "assign an expression to a variable" -- and what that does in the machine in terms of language constructs, is semantics.

"Meaning" as it takes place in human heads is not directly measurable. Two interpreters having similar behavior (I/O profile) only tells us they have similar behavior. To say anything about some supernatural force called "semantics" is not useful because it's not scientifically analyzable (so far). It's useless to talk about such, it does not help communication. Please stop. I can say interpreters have a force called Zazzo in them. You can neither confirm nor deny it's existence in interpreters. "Semantics" is no more meaningful to me than Zazzo.

Meaning as it takes place in human heads is irrelevant for our purposes, and it only matters to programmers to the extent that they need to understand how programming languages work in order to use them. Our interest in language semantics -- as software engineers, computer scientists, or language designers -- ends long before we reach the point of considering a programmer's interpretation of language semantics. As a language designer, it is sufficient to document the intended semantics -- using English, formal notations, code examples, or a reference implementation -- and from that a compiler/interpreter author can create a compiler or interpreter that implements them.

Their "work" is defined in terms of behavior. And written descriptions sometimes employ UsefulLies, yes, but that does not make them universal truths.

What does this have to do with UsefulLies? Semantics defines behaviour; semantics also defines static structures, relationships between language components, and so on.

Semantics also scratch my itches while I'm asleep. Prove it doesn't. Enough of your SemanticsReligion?.

You're quibbling.

Quibbling over lack of science? Guilty!

You appear to be assuming the only science is observation-based natural science, ignoring the fact that mathematical disciplines (like ComputerScience) are even more rigorous.

Math is what we use to communicate and document models of reality. Ideally, all parts of models should be tested against reality to make sure there is not a problem somewhere with assumptions/givens or math/model derivation or computation mistakes. (In practice we spot-check instead of check everything.) However, I don't really see how it's relevant here since this is no mathematical model of semantics actually being used in these debates.

[That is one use to which we put it, but it's not the only one. And even if it were, it still wouldn't make applying natural science techniques appropriate. Your final point is also incorrect. Some of the semantics under discussion have been mathematical and the one on TypeSystemCategoriesInImperativeLanguages is a portion of a mathematical one presented informally. Other models have been physical, as in the ones implemented in compilers and interpreters.]

TypeSystemCategoriesInImperativeLanguages has models that may be influenced by semantics, but that's not the same as mathematically examining semantics, such as determining equivalency of semantics from one model to another or one language to another.

{Mathematically examining semantics can be done with DenotationalSemantics and other formalisms, but I don't think that's necessary in order to recognise the simple and inarguable fact that "a = foo() + b;" has the same semantics in every popular imperative programming language.}

Sorry, I have to disagree. There are multiple different mental models that can process or analyze such expressions similar to how there are different algorithms to process it. Again, you seem to be mistaking your personal preference or existing mental model for a universal truth.

{"Mental models" are irrelevant. However, even if we consider programmer's "mental models", it's highly unlikely that a programmer will have one mental model for "a = foo() + b;" in Python and a completely different mental model for "a = foo() + b;" in PHP. Do you have different mental models for "a = foo() + b;" in Python and PHP?}

But one can often just cross-translate one into the other, like I already described. One may be mentally syntactically translating PHP into VBS in their head if they are used to VBS and are a newbie at Php. Thus, it could be only a single "semantic" with mostly syntactical translation. Further, that says nothing about inter-mind semantics even IF an individual were using the "same semantics" for common dynamic languages. Studies on monkeys who have their arms chopped off and then have a prosthetic robot limb added shows they use the same "arm" portion of their brain (via scans) to successfully control the prosthetic limp. They don't have to grow a brand new "limb lobe", they reuse what's already there and just translate at a higher level. The monkeys are using reusing the same "arm semantics".

{The fact that you can "cross-translate" from one language to another based on common syntax is proof of identical semantics.}

In a specific head? Maybe, but that's not a useful fact for our purposes. It says nothing about a shared semantics among similar languages or among different heads. It can be "explained" by using a single instance of semantic, plus syntactical translation, to get by using a single semantic in an individual's head. There's no "common semantics" there's only ONE semantic. It's not "identical" (your word), it's the same instance. "Identical" implies copies that are equivalent. There's is no copy in this scenario. I suppose the same identical "thing" is by definition identical to itself, but that's a UselessTruth.

{No, how language semantics are interpreted by a "specific head" or "different heads" is irrelevant. The fact that a statement like "a = foo() + b;" will perform the same computations at run-time in all popular imperative programming languages (modulo those differences in TypeSystem behaviour documented on TypeSystemCategoriesInImperativeLanguages) is proof of identical semantics.}

Please use ItemizedClearLogic. You are not showing some steps to your (alleged) reasoning.

{1. Select a popular imperative programming language.}

{2. Start up the language's text editor, IDE, or interactive environment. Write a function called 'foo' that takes no parameters and returns 3.}

{3. Declare a variable 'b' and assign it 4. If necessary, declare variable 'a'.}

{4. Write "a = foo() + b;", or the equivalent in the language's syntax.}

{5. Write a statement to write out the value of variable 'a'.}

{6. Run the program. Note down what it writes out.}

{7. Repeat steps 2 through 6 on all popular imperative programming languages.}

{8. Observe that the result is 7 in every case. Therefore, the semantics of the above must be the same in every case.}

FacePalm. Okay, let's roll with it. Where does your "Therefore" association in step 8 come from? What logic rule are you applying?

{I'm using equality.}

Of what? You appear to be making up operators without citations to logic rules or the like. It seems an instance of ThenaMiracleOccurs.

{Of the sevens. You are aware that every 7 is the same 7, so they are "equal", yes?}

Are you saying that numerical equality is the same as semantics equality? Your "proof" needs more StepwiseRefinement, or it's logical equivalent.

{No. The fact that an example of almost identical syntax for a given statement -- run in all popular imperative programming languages -- results in the same run-time behaviour (as demonstrated by equal results) is evidence of the same semantics.}

That's a claim, not a proof. And "is evidence of" may be true as a necessary condition (aka, prerequisite, which I don't necessary dispute), but may not be a sufficient condition to say "semantics are same". You need to establish it as a sufficient condition.

{Yes, it's a claim because "Repeat steps 2 through 6 on all popular imperative programming languages" is not and cannot be a logical statement. However, it can be tested empirically. Try it and see.}

Further, it almost looks like you are using the I/O profile to measure equivalent semantics, but you have rejected that in the past.

{I don't recognise "I/O profile" as being meaningful, so I neither promote nor demote statements that perform I/O. I don't treat them as any different from any other statements, so I may include them or exclude them as I see fit.}

If you don't recognize it, what alternative do you use to compare and verify that one interpreter is equivalent to another (runs the same language)? Assume poorly written manuals for now.

{I don't preclude using I/O as part of empirical verification of semantics, but it's hardly the sole means for grasping language semantics, and I certainly don't regard I/O as any more or less significant than any other means. You can also read the documentation -- "poorly written" does not preclude understanding language semantics -- or examine the run-time behaviour of statements in a debugger.}

I consider the I/O profile the best arbiter of language and interpreter equivalency. There are indeed multiple ways to "learn about" languages, but they each have weak areas. English documentation can be vague in certain areas, and debuggers can "leak" implementation specifics, and may not represent "output" well and/or be different per language vendor, for example. But in this context, we are talking about proof, not about learning.


Syntax and semantics are clear to me. Here is some syntax in a dynamic, MultiValued language.

 1. Customer.Id = Save.Attribute.Values("Customers", "Name", "", "ACME")
 2. Name = Get.Attribute.Values("Customers", "Name", Customer.Id)
   ==> Name now contains "ACME"

The syntax is ClearEncapsulation. The semantics -

-- ChaunceyGardiner

I'm not sure what your general point is. This is not about interpreting app code. -t

If an entry showing a (hopefully) simple example of a difference between syntax and semantics is inappropriate on a page called semantics discussion, then perhaps I am misinterpreting the name. I would probably grok it more quickly if it were called TopsSemanticsDiscussion?.

Why does everyone use English to represent semantics, and say "this is the semantics..."? It's your personal interpretation of semantics. What we are looking for is a more objective way to compare and contrast semantics. English conversion of mental semantics has left a lot to be desired in these debates.

[They don't. If we were two people who spoke only Russian, we would be using Russian instead of English. We're using English here because it's the language of choice here.]

I doubt using Russian would free it from similar problems. English, as usually used, is insufficiently rigorous for our needs, such as measuring semantic equality.

It's entirely possible to represent semantics without using human language. DenotationalSemantics is a good example.

Then use it to prove your similarity/equivalency claims. Plus, you haven't demonstrated that DS is capturing ONLY semantics and not something else, such as restated algorithms mislabeled as "semantics". We've been over this already. Do we really need to reinvent this fight here again?

What is a "restated algorithm mislabeled as 'semantics'"? Semantics refers to the meaning (in both human and computational terms) of language statements. How would a language statement be a "restated algorithm"?

How do we know that whatever notation "comes out of" DS represents/encodes "semantics" and not the other things mentioned?

A language consists only of syntax and semantics, so if what's being described isn't syntax -- for which we have EBNF and other formal notations -- then it must be semantics. Note also that DenotationalSemantics merely formalises what we can explain in English or any other informal (but humanly-understandable) language. I don't know of any programming language reference manual -- which is a description of language syntax and semantics -- that contains a "restated algorithm mislabelled as 'semantics'", so I don't know why DenotationalSemantics would somehow capture it.

Syntax or semantics might be true of the language(s) itself, but not necessarily of what DS generates. In other words, limits on what a language must be don't necessarily apply to DS results. You seem to be conflating them. It may be generating an algorithm, for example. And many language manuals do describe some statements/operations using algorithms. I'd even argue that's how the better manuals do it because it's often clearer that way. Plus, instructions normally don't classify themselves such that not seeing a mis-classification doesn't tell us much. A mute person rarely misspeaks.

I'm afraid I don't follow any of this, except for "And many language manuals do describe some statements/operations using algorithms." It is true that the semantics of some operators can be described algorithmically. DenotationalSemantics describes them formulaic-ally. How does that relate to a "restated algorithm mislabeled as 'semantics'"?

I don't know why you can't follow any of it. It's clear to me, upon review. I don't know where the communication breakdown is happening such that I cannot "fix it". How do we know that the formulas generated by DS are "semantics" and not just "algorithms" restated in another way? DS produces something, I'll call X. How do we know that X is semantics and not something else? Remember, I'm asking this about DS, not about "programming languages"; thus your statement "A language consists only of syntax and semantics, so if..." does NOT apply. I'm asking about characteristics of DS's output, not (directly) about programming languages at this point. (That's a later step.)

I don't know what the question "how do we know that the formulas generated by DS are 'semantics' and not just 'algorithms'?" means. It makes even less sense than "how do we know that elementary arithmetic expressions are 'simple mathematical formulae' and not just instructions for building a pocket calculator?" Do you understand what denotational semantics are?

I'm not sure, but my answer doesn't excuse you from proving that the output of DS is semantics and only semantics (or at least is free of algorithms). If you say the output of X only contains Y, then prove it only contains Y. Whether I understand X is irrelevant to your proof. Your proof wouldn't care if I was dumb.

I no more need to prove that "the output of DS is semantics" than I need to prove that "the output" of a blue-print is a floor-plan and free of circuit diagrams. I no more need to prove that "the output of DS is semantics" than I need to prove that the Python reference manual is about the Python programming language free of instructions on how to create French poetry.

That's a copout. Generally one can provide evidence that something is an X instead of Y if they are not bullshitting. Circuit diagrams have certain features that floor-plans lack and vice verse and one can catalog existing features and compare occurrences of such features with agreed-upon representative samples, etc. "Shut up and trust me" is not acceptable.

It's not a case of "shut up and trust me", it's a case of "why the bizarre demand?" It's like asking for proof that the source code for a Javascript program isn't a French poem encoded in JSON. I don't know how I'd prove that, either. Your demand for "proof" is so non-sequitur I don't even know where to start, other than to repeat my previous question: Do you understand what denotational semantics are? I suspect if you did, you wouldn't ask.

Sorry, I don't see it as "bizarre". It's a perfectly good question. If you cannot answer that, than admit it like an honest man rather than insult the request.

It's a peculiar question, at least. I find it as strange as showing a picture of a cat, and being asked to prove how I can tell it isn't a car.

Just because it looks like a cat to you does not mean it does to others. You seem to be mistaking your personal head model for some universal truth. "I know it when I see it, so shut up and trust me" is not good enough.

You're quibbling. Requiring that every formalism about <x> prove that it's actually about <x> is unreasonable, and unnecessary, as is requiring that every claim of writing about <x> demonstrate that it's actually about <x>. If a document purports to be about <x> but is actually about <y>, it will inevitably become clear, sooner or later.

What's this "every" stuff? I only requested it for one situation. You are drama-queening. I'm highly skeptical the claimed item is "pure semantics".

Given that DenotationalSemantics is merely one formalism among many -- possessing no special or distinguishing attributes -- I can only assume that if you insist that it be proven that DenotationalSemantics is about semantics, then you must insist that it be shown that every formalism about <x> is actually about <x>. Otherwise, why do you single out DenotationalSemantics for special scrutiny?

I don't see why that's a global requirement. As mentioned before, as long as two parties agree on a given base fact, there is no reason to argue or question it. There are plenty of NON-agreements to debate such that gumming up the works proving things both sides already agree on should be a low priority in comparison. If you personally want to prove everything under the sun, go for it, Sheldon.

That doesn't answer my question, and doesn't appear to be related to it.

What is "pure semantics"?

Semantics, or a representation of, lacking syntactic and algorithm information, at least.

Can you given an example of non-"pure semantics", particularly using DenotationalSemantics?

The example in that topic that has a rule that syntax in the form of the left side "means" an operation/function described on the right side:

   [[A + B]] = plus([[A]], [[B]])
That is or can be viewed as a partial algorithm that can be used for the purposes of interpreting/compiling language statements. True, one does not have to use it as an algorithm or part of an algorithm, but again "meaning" and "intention" happens in human heads and different heads may do different things with the same given info.

An algorithm is a set of steps to be followed to solve a problem. I see no steps, only an equivalence of a syntactic construct to a construct in some other (perhaps mathematical, or perhaps the implementation language) domain.

An algorithm does NOT have to be "steps". Functional and logical algorithms can lack explicit "steps", for example.

[The definition of "algorithm" is "a set of steps to be followed to solve a problem." (There's an alternate wording at http://en.wikipedia.org/wiki/Algorithm .) It immediately follows that algorithms have to be composed of steps.]

So a logic-constraint type of language, such as non-procedural queries, are not "algorithms"? I don't believe most would agree with that. Those definitions are probably colloquial definitions and not industry-vetted. And even if they were not, they are still not "semantics" any more than queries are "semantics". It appears to me that DS is merely producing alternative syntax for languages that perhaps may aid in analysis, but this is not necessary pure "meaning". It looks more like a half-ass interpreter meta language. It's similar to a device that builds an AbstractSyntaxTree. Would such a device be called a "semantics extractor"? Perhaps, perhaps not, but it's not necessarily isolating unique semantics, but merely one of multiple possible semantics.

[That is correct, the non-procedural queries would not be an algorithm. Those definitions are the ones provided by the industry, so they are industry-vetted. As for what appears to you, it would help if you opened your eyes. DenotationalSemantics are not half-ass, do tell you what meaning to assign to what language constructs (and is therefore semantics). I don't think anyone would call a device that builds AbstractSyntaxTrees a "semantics extractor". (Hint: It's not an abstract semantic tree.) The "pure" and "uniqueness" constraints are yours and yours alone and aren't necessary.]

Interpreters/compilers also tell the computer "what meaning to assign to what language constructs". Compilers describe such "meaning" in terms of machine code or machine code patterns and DS uses a kind of meta language. Machine code may not be very friendly to read, but that's a quality/target-audience question, not a definitional issue. Nor are the results unique. And I did not say the AbstractSyntaxTree was the semantics extractor itself. I suggest you reread it.

Such a meta language may be quite useful for a compiler designed for multiple hardware platforms (CPU chip instruction sets) so that we only have to build one "front end" compiler to do roughly half the work, and a meta-language-to-machine-language translator "back end" would be built for each chip type to translate the meta language to the target machine language. (This is somewhat like Microsoft's CLR.) But such a meta language is not "pure semantics". It's at least partially algorithmic information. Nor is it unique: there are multiple ways to define and build such meta languages. Thus, even if by some stretch we consider such meta language "semantics", it does not prove a unique or canonical semantics for a given language family. Perhaps we can force it to be the same for a target family, but this itself does not necessarily prove canonical-ness because we can't rule out the similarity being due to artificial decisions that have the intent/goal of forcing similarity. The existence of semantics was not our point of contention, but COMPARING semantics to objectively say the semantics of X are the same as the semantics for Y. That's our ultimate goal.

DS doesn't produce a meta version of the app source code, but is more like a meta language for meta language producers. I'm not sure I'm saying that right. I'm lacking for a way to describe it well in English right now.

[You most certainly aren't.]


English Redux

  a = b + c * d
Person A: "Multiply c by d, and then add the result to b, and store that result in a".

Person B: "Push c and d onto the stack, apply multiplication reduction to the stack. Push b onto the stack and then apply addition reduction to the stack. Label the topmost element of the stack 'a'."

You seem to be calling descriptions similar to person A's description "semantics" and person B's description an "implementation suggestion" or an "algorithm".

However, I see no reason to make a classification distinction. A's description is also an algorithm. A's approach is generally how we learn to describe and process it in grade school and thus it's more entrenched human-wise. But it's just as arbitrary if we remove such upbringing influence. You can call both "semantics" if you want, but then you are agreeing that implementation and semantics are or can be the same thing, at least as English descriptions. (Notice how B does not really need a "store" step. Thus, "store" is not universal either.) -t

The above is a poor example, conflating the process of expression evaluation with the semantics which are simply, at a high level, "assign the result of evaluating an expression to 'a'".

A better example is the following. Imagine a language that has an operator 'sort' to sort a list or array. So, a statement like "a = sort b;" has the semantics "store the result of sorting 'b' in 'a'". That is quite distinct from the implementation and/or algorithm, which could be:

        void Quicksort(IComparable[] elements, int left, int right)
        {
            int i = left, j = right;
            IComparable pivot = elements[(left + right) / 2];
            while (i <= j) {
                while (elements[i].CompareTo(pivot) < 0) {i++;}
                while (elements[j].CompareTo(pivot) > 0) {j--;}
                if (i <= j) {
                    IComparable tmp = elements[i];
                    elements[i] = elements[j];
                    elements[j] = tmp;
                    i++;
                    j--;
                }
            }
            if (left < j) {
                Quicksort(elements, left, j);
            }
            if (i < right) {
                Quicksort(elements, i, right);
            }
        }

IComparable[] tmp = (IComparable[])Expression.Evaluate('b'); Quicksort(tmp, 0, tmp.Length - 1); Variable.Assign('a', tmp);

I agree they are very different, but that does not tell us precisely what the first thing is in terms of classification.

The first thing is an expression assigned to a variable. That's what it means, and therefore that is its semantics.

As described above near PageAnchor pattern-839, that could merely be a language pattern that is associated with a syntax pattern through habit or convention. It's not necessarily "meaning". Providing an alias is not necessarily meaning.

You're talking about how it might be inferred. Inference is irrelevant. I know of no popular imperative programming language where it would not have been specified as an expression assigned to a variable.

I'm not sure what you mean by "inferred" in this context. Manuals and training materials follow certain conventions of description, true, but that does not necessarily make those conventions "meaning". They can merely be conventions that are treated as aliases of the kind described near PageAnchor pattern-839. You see "foo is assigned to thing" and you can just mentally translate that to "thing = foo" out of tradition by studying word occurrence patterns in the books. Even a non-English speaker can do such because it's a pattern that can be learned without mentally associating meaning to each of the words or phrases. It's one of the reasons why foreign students often do so well in math in US universities despite flunking out of English 101. If you have a near-photographic memory, you must memorize word pattern usage in math books and plug in the "linguistic parameters" where appropriate. As long as the tests keep to the same conventions, the test taker can apply such linguistic substitution and get a good grade. -t

Again, you're making reference to inference rather than specification. Semantics are specified. Language statements mean what the language designer wants them to mean.

No, meaning is whatever anybody wants meaning to be. The language author cannot prevent me from using my favorite model etc. in my head to predict language behavior. Any documentation by the language author is a suggested model/description only. They are not God and their writing is not The Bible.

You're confusing "meaning" with "interpretation". Language statements mean what the language designer wants them to mean. How meaning is interpreted is up to each individual. Of course, when an individual is the author of a compiler or interpreter, hopefully there is a close concordance between the semantics intended by the language designer and the semantics implemented by the compiler/interpreter author.

You haven't demonstrated that they are fully distinct. One can use whatever model their head wants to analyze and predict source code. Nobody can stop them, not the language author and not you. -t

Well that has cleared that up. --AnonymousDonor


DecemberThirteen


EditText of this page (last edited August 21, 2014) or FindPage with title or text search