as the Amazon app wants to switch country and closes if I don't. (party pooper).

from the Preface:

Laboratory Activities

Chapter 2: Scanning and parsing Wren

Chapter 3: Context checking Wren using an attribute grammar

Chapter 4: Context checking Hollerith literals using a two-level grammar

Chapter 5: Evaluating the lambda calculus using its reduction rules

Chapter 6: Self-definition of Scheme (Lisp) Self-definition of Prolog

Chapter 7: Translating (compiling) Wren programs following an attribute grammar

Chapter 8: Interpreting the lambda calculus using the SECD machine Interpreting Wren according to a definition using structural operational semantics

Chapter 9: Interpreting Wren following a denotational specification

Chapter 10: Evaluating a lambda calculus that includes recursive defini- tions

Chapter 12: Interpreting Wren according to an algebraic specification of the language

Chapter 13: Translating Pelican programs into action notation following a specification in action semantics.

Syntax is the smallest scale (words, punctuation, grammar), semantics is sentence or small function level, and pragmatics is paragraph-essay and program level.

For example when training early smaller scale LLMs they noticed that syntax was the first property for the LLM to reproduce reliably. They got proper grammar and punctuation but the sentences made no sense. When they scaled up they got semantics but not pragmatics. The sentences made sense but paragraphs didn't. Eventually the systems could output whole essays that made sense.

Even though you're asking about programming specifically, these concepts are universal to language, and are maybe a bit more intuitively applied to English (or your native language).

I suspect that a computer scientist could give a different mathematical explanation about how these concepts compile into binary or machine code in different ways, and I can't explain that. Generally I think of syntax as being very language specific but semantics and pragmatics can be translated across languages with similar capabilities.

Arguably this is also semantics. Type checking and reporting type errors decides whether a construct is allowed or not, yet belongs squarely in the semantic analysis phase of a language (as opposed to the syntactic analysis phase).

> how it differs from syntax

Consider a language like C, which allows code like this:

    if (condition) {
        doWhenTrue();
    }

    if condition:
        doWhenTrue()

The syntax is different: C requires parens around the condition, allows curly braces around the body, and requires `;` at the end of statements. Python allows but does not require parens around the condition, requires a `:`, requires indenting the body, and does not allow a `;` at the end of statements.

Also, the semantics are different: in C, `doWhenTrue()` only executes if `condition` either is a non-zero integer, or can be implicitly coerced to a non-zero integer.

In Python, `doWhenTrue` executes if `condition` is "truthy," which is defined as whether calling `condition.__bool__()` returns `True`. Values like `True`, non-zero numbers, non-empty containers, etc. are all truthy, which is far more values than in C.

But you could imagine a dialect of Python that used the exact same syntax from C, but the semantics from Python. e.g., a language where

    if (condition) {
        doWhenTrue();
    }

Your intuition is right. It falls under what is called "Operational Semantics" (https://en.wikipedia.org/wiki/Operational_semantics) There are other aspects of looking at it i.e. "Denotational Semantics", "Axiomatic Semantics", "Algebraic Semantics" etc. which are more mathematical. The submitted book talks about all of them.

For more background, you might want to look at Alan Parkes book Introduction to Languages, Machines, and Logic.

The basic idea is that Symbolic Logic allows you to express Strings (sentences containing words) constructed from an Alphabet (set of symbols for that language) as "Programs" (which are valid i.e. meaningful strings in that language) which can then be interpreted by a Abstract Machine we call a Computer.

"Syntax" just means what strings are valid programs. For example, x=3 should be valid in C, while =+x shouldn't. Note that this doesn't say anything about what x=3 actually means in practice. The fact that there is a variable called x, and that it has a value at some point in time, and that after the execution of x=3 that value becomes 3 are all semantics.

1. There's a lexer which breaks source text up into a stream of tokens.

2. A parser which converts a stream of tokens into an abstract syntax tree (AST).

3. An interpreter or compiler that traverses the AST in order to either execute it (interpreter) or transform it into some other form (compiler).

Points 1 & 2 are syntax - the mapping between the textual form of a program and its meaning.

Point 3 is semantics - how a program actually behaves, or as you say, what its terms evaluate to.

Looking at it like this can give a sharp line between syntax and semantics. But when you get deeper into it, it turns out that with some languages at least, you can get from source syntax to something that actually executes - has behavior, i.e. semantics - with nothing but a series of syntactic transformations. From that perspective, you can say that semantics can be defined as a sequence of syntactic transformations.

This doesn't erase the distinction between syntax and semantics, though. The syntax of the source language is the first stage in a chain of transformations, with each stage involving a different (albeit closely related) language with its own syntactic structure.

> Explanations that involve 'giving a precise mathematical meaning' just seem almost circular to me.

Formal semantics covers this, but the syntax/semantics distinction isn't necessary just formal - it's a useful distinction even in an informal sense.

As for circularity, it's absolutely the case that formal semantics is nothing more than defining one language in terms of another. But the idea is that the target language is supposed to be one with well-defined semantics of its own, which is why "mathematical" comes up so often in this context. Mathematical abstractions such as set theory, lattice theory, lambda calculus and so on can provide a rigorous foundation that's more tractable when it comes to proofs.

That kind of circularity pervades our knowledge in general. Words in the dictionary are given meaning in terms of other words. You can't explain something without explaining it in terms of something else.

Consider a simple calculator language that lets you add positive integers.

The syntax might give grammar rules like:

    expr ::= digits (EOF | ' + ' expr)
    digits ::= ('0' | '1' | ... | '9')+

But how the language interprets those expressions is semantics. Continuing our calculator example:

1. Every expr evaluates to an integer value.

2. An expr of the form `<digits> EOF` evaluates to the integer given by interpreting the digits in <digits> as an integer in base 10.

3. If <expr> evaluates to the value x, then an expr of the form `<digits> + <expr>` evaluates to the value y + x, where y is the integer given by interpreting the digits in <digits> as an integer in base 10.

Of course, specifying semantics in human language is tedious and hard to make precise. For this reason, most programming languages give their semantics in a more formalized language. See, for a classic example, the R5RS specs for Scheme:

https://conservatory.scheme.org/schemers/Documents/Standards...