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) |
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]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.