Do you always use the word "meaning" or do you sometimes use the word >"semantics"? Do the two words mean (no pun intended) the same thing to you, >from a compiler perspective?
In some book I read this statement:
The meaning of an expression is
the value of the expression.
Today while reading the Bison manual, I noticed in it a sentence that said:
... the meaning of a variable ...
[I think the meaning here is not to believe everything you read. -John]
Hello Compiler Experts!
In some book I read this statement:
The meaning of an expression is
the value of the expression.
The meaning of an expression is the value of the expression.
The semantics of an expression is the value of the expression.
Hello Compiler Experts!
In some book I read this statement:
The meaning of an expression is
the value of the expression.
For example, the meaning of this expression:
1 + 1
is 2.
Is the statement something that you would say?
The mathematicians and linguists that I spoke to thought the statement
was crazy.
For example, the meaning of this expression:
1 + 1
is 2.
On Friday, January 14, 2022 at 6:40:24 PM UTC+1, Roger L Costello wrote:
For example, the meaning of this expression:
1 + 1
is 2.
The meaning of 1+1 is a transition between two states. ....
-atom
[We seem to be pretty deep in this tarpit now. -John]
Now we're even deeper in the tarpit. Is the "meaning" a mathematical statement,
an instruction to a compiler to generate code computing the value of an expression,
something else? I don't know, and it's pretty clear none of the rest of us do either.
-John
[If you go back the the start of the thread, someone asked about
a statement that "The meaning of an expression is the value of the expression."
I suppose we could ask what it means to a compiler but that seems awfully anthropomorphic. -John]
So, back to anthropomorphic computers and logical
inconsistencies. How good are compilers, especially ones
that evaluate constant expressions at compile time, at
dealing with logic failure?
And especially, as the question
needs, expressions that don't have a value?
On 1/19/22 12:18 AM, gah4 wrote:
So, back to anthropomorphic computers and logicalOptimization is a special science. A compiler might evaluate a constant expression properly, in the sense that evaluation at runtime might fail
inconsistencies. How good are compilers, especially ones
that evaluate constant expressions at compile time, at
dealing with logic failure?
due to overflows of too narrow types in compiled code.
And especially, as the questionAren't these called *statements*?
needs, expressions that don't have a value?
In some book I read this statement:
The meaning of an expression is
the value of the expression.
So, back to anthropomorphic computers and logical
inconsistencies. How good are compilers, especially ones
that evaluate constant expressions at compile time, at
dealing with logic failure?
An analogy: There exist two kinds of compression algorithms: lossy and lossless. Similarly, there exist two kinds of optimization algorithms. If it is a lossless optimization algorithm, then any kind of difference between compile-time evaluation and run-time evaluation is a software bug in the optimizer. If it is a lossy optimization algorithm, then it should be sufficiently clearly specified what kind of information is permitted to be lost during the optimization process.
On Wednesday, January 19, 2022 at 4:13:36 PM UTC+1, Hans-Peter Diettrich wrote:
On 1/19/22 12:18 AM, gah4 wrote:
And especially, as the questionAren't these called *statements*?
needs, expressions that don't have a value?
One could imagine that, as a minimal requirement that has to be fulfilled by any statement, the "value" of a statement X must include information about what the next statement is after X is done executing, unless the programmer or
the compiler proves that the statement never terminates by itself.
Back to the original post by Roger L Costello: A problem with both "The meaning of an expression is its value" and "The semantics of an expression is the value of the expression" is that some expressions never return a value
The second one was from my own experience working on the Alpha
optimizer at DEC. The C++ compiler was one of the last pieces of
software to use the one based upon Fred Chow's work. That was my responsibility at the time (the optimizer, not the C++ compiler). In
any case, the front end writers were very aggressive in inlining
subroutines and doing whole-program optimization by that trick.
The result was very massive files of the intermediate representation. The result, for certain large (and important) C++ programs the compiler
would work for days before it had filled up all the paging space on
the engineering cluster at DEC, which was multiple disks of paging and
as a result crashed not only the compiler, but in some cases the
entire cluster. This made for some very unhappy users, because they
had waited days and they still didn't get a successful compilation.
Fortunately, a small amount of analysis on my part allowed me to
realize that most of the optimizers data structures while N-squared in
size, were actually filled with mostly zero values.
ARAIR K&R C defined the value of a function call to be the value...
contained in the accumulator after return. A decision with horrible consequences if you look at compiler and library source code of that
time. OTOH it derogates the meaning of an expression if at any time one
can find a value in the defined result register.
[Early C didn't have default return values, but since the compilers also didn't do much type checking, I can believe there was a code that
worked by accident becaues the value of the last expression in a function happened to be in the register where the caller looked for the result. ...]
Of course, expressions in most languages can also include function calls and operators that produce side effects, like "printf("%d",++i);", which certainly
has a meaning even though it produces no meaningful value.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 296 |
Nodes: | 16 (2 / 14) |
Uptime: | 61:37:55 |
Calls: | 6,654 |
Files: | 12,200 |
Messages: | 5,331,534 |