Re: What is the meaning of an expression?

Hans-Peter Diettrich <DrDiettrich1@netscape.net>
Thu, 20 Jan 2022 13:02:34 +0100

          From comp.compilers

Related articles
[10 earlier articles]
Re: What is the meaning of an expression? gah4@u.washington.edu (gah4) (2022-01-18)
Re: What is the meaning of an expression? DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2022-01-19)
Re: What is the meaning of an expression? 0xe2.0x9a.0x9b@gmail.com (Jan Ziak) (2022-01-19)
Re: What is the meaning of an expression? christopher.f.clark@compiler-resources.com (Christopher F Clark) (2022-01-19)
Re: What is the meaning of an expression? tkoenig@netcologne.de (Thomas Koenig) (2022-01-19)
Re: What is the meaning of an expression? gah4@u.washington.edu (gah4) (2022-01-19)
Re: What is the meaning of an expression? DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2022-01-20)
Re: What is the meaning of an expression? tkoenig@netcologne.de (Thomas Koenig) (2022-01-22)
Re: What is the meaning of an expression? dave_thompson_2@comcast.net (2022-01-30)
Re: What is the meaning of an expression? johann@myrkraverk.invalid (Johann 'Myrkraverk' Oskarsson) (2022-02-03)
| List of all articles for this month |

From: Hans-Peter Diettrich <DrDiettrich1@netscape.net>
Newsgroups: comp.compilers
Date: Thu, 20 Jan 2022 13:02:34 +0100
Organization: Compilers Central
References: <AdgJPKhi/NiNfECvRNaA6+4Wq/M8OQ==> 22-01-052 22-01-060 22-01-066 22-01-067 22-01-068 22-01-069 22-01-070
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="64223"; mail-complaints-to="abuse@iecc.com"
Keywords: design
Posted-Date: 20 Jan 2022 12:41:36 EST
In-Reply-To: 22-01-070
Content-Language: de-DE

On 1/19/22 6:17 PM, Jan Ziak wrote:
> 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 question
>>> needs, expressions that don't have a value?
>> Aren't these called *statements*?
>
> 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.


Can you please specify the language you have in mind?


Languages like C or Pascal distinguish expressions from statements in
their grammar. Allowed is to ignore the value (result) of an expression
evaluation but not to use a non-expression as a value.




> 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


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.


So I think that it's moot to discuss obscure languages that do not
strictly distinguish expressions from statements. At the abstract level
we could try to define what *is* an expression, with my favorite:
"Evaluation of an expression yields a value."
Then it should be clear that the meaning of an expression is a value.


DoDi
[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.
It's sort of like the Berkeley bug, that there was always a zero byte at
memory location zero so dereferencing null pointers sort of worked. -John]





Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.