> And do you think the implementation isn't a mathematical object itself?

Only if you're taking the Tengmark "mathematical universe" view. The implementation is not necessarily any more mathematical than, say, a table.

> This is a contradiction in terms. By definition a semantics is a mathematical descrpition of the meaning of a programming language, i.e., the behavior of its programs. Sometimes a semantics exposes significant differences between the mental model of programmers and what a programming language really is, but the solution is not to turn a blind eye to reality.

The meaning expressed in a language is some alignment of what the writer intended and what the reader understood. If different readers don't reach a shared understanding then there is no meaning. It would be desirable for our programs to always have meanings that aligned with their behaviour, but we shouldn't turn a blind eye to the fact that many programs don't.

> So long as they have object identities, they are not values. Values are merely represented in memory - they truly exist in the language's semantics.

Any practical programming language will give you some way to find the memory address of a particular value, so values that we usually consider as semantically identical are not actually indistinguishable in practice. We deal with this by only assigning semantics to a subset of the language that excludes those operations. Python without "is" may be more obviously a subset than, say, Haskell without unsafeCoerce, but both are subsets.

> It would be desirable for our programs to always have meanings that aligned with their behaviour, but we shouldn't turn a blind eye to the fact that many programs don't.

The meaning of a program is its behavior, period. If reality doesn't agree with your views, it's your fault, not reality's.

> Any practical programming language will give you some way to find the memory address of a particular value, so values that we usually consider as semantically identical are not actually indistinguishable in practice.

Standard ML doesn't give you any way to get the memory address of a particular value, so values that are semantically identical are actually indistinguishable in practice.

> We deal with this by only assigning semantics to a subset of the language that excludes those operations.

That doesn't make sense. Semantics is a property of the real programming language you are using, not the fictitious one you wish you were using.

> The meaning of a program is its behavior, period. If reality doesn't agree with your views, it's your fault, not reality's.

That's not the usual meaning of, well, meaning.

> Standard ML doesn't give you any way to get the memory address of a particular value, so values that are semantically identical are actually indistinguishable in practice.

Just tried it to be sure:

    fun address i = Unsafe.cast(ref i) : Int32.int ;;
    val a = 4 :: nil ;;
    val b = 4 :: nil ;;
    address (a) ;;
    address (b) ;;
    address (a) ;;

And yep, a and b are semantically identical values but distinguishable in practice:

    val address = fn : 'a -> Int32.int
    val a = [4] : int list
    val b = [4] : int list
    val it = ~175003712 : Int32.int
    val it = ~174998232 : Int32.int
    val it = ~175003712 : Int32.int

SML/NJ is not an implementation of Standard ML. It's known to be non-conformant in several ways: http://mlton.org/SMLNJDeviations

If SML/NJ doesn't count as Standard ML then I'd say Standard ML doesn't count as a practical programming language.

I use MLton and Poly/ML on a daily basis. No problems with them at all.