Board index » delphi » Pascal's Evaluation Order

Pascal's Evaluation Order

Hi,
  I need your help. Does the Pascal standard specify any expression order of
evaluation. For example, in C an expression like a[i]=i++; is undefined by the
standard as how it will work, i.e. will i be incremented before or after the
index evaluation. Is this left out in Pascal for example in a statement like
k=j+func(&j); with j being changed...! Does the standard specify how this will
be evaluated exactly.

Thanks,
Fahd

 

Re:Pascal's Evaluation Order


Quote
"ALBINALI4" <albina...@aol.com> wrote in message

news:20020122113102.29577.00000520@mb-cq.aol.com...

Quote
> Hi,
>   I need your help. Does the Pascal standard specify any expression order
of
> evaluation. For example, in C an expression like a[i]=i++; is undefined by
the
> standard as how it will work, i.e. will i be incremented before or after
the
> index evaluation. Is this left out in Pascal for example in a statement
like
> k=j+func(&j); with j being changed...! Does the standard specify how this
will
> be evaluated exactly.

Even if it does, the fact that you have to ask this question means that such
expressions should be avoided. Use

k := func(j);
k := k+j;

or

k := k+j;
k := func(j);

and then another programmer reading your code - or you yourself in, say, 6
months - will know which evaluation order is intended.

FP

Re:Pascal's Evaluation Order


Quote
"ALBINALI4" <albina...@aol.com> wrote in message

news:20020122113102.29577.00000520@mb-cq.aol.com...

Quote
> Hi,
>   I need your help. Does the Pascal standard specify any expression order
of
> evaluation. For example, in C an expression like a[i]=i++; is undefined by
the
> standard as how it will work, i.e. will i be incremented before or after
the
> index evaluation. Is this left out in Pascal for example in a statement
like
> k=j+func(&j); with j being changed...! Does the standard specify how this
will
> be evaluated exactly.

> Thanks,
> Fahd

I don't know, but suspect it's compiler-dependent - but imho that's the
wrong question. Even if the standard does specify the order for expressions
like this, the fact that you have to ask this question means that such
expressions should be avoided. Use

k := func(j);
k := k+j;

if you expected the function to be called first, or

k := j;
k := k+func(j);

if that was what you meant, and then another programmer reading your code -
or you yourself in, say, 6 months - will know which evaluation order you
intended.

FP

Re:Pascal's Evaluation Order


Well.. I am really interested in analyzing the language itself rather than
writing unambigious programs .. -:) Thank you anyways... I agree its a bad
practice that should be surely avoided.
Fahd

Re:Pascal's Evaluation Order


Im Artikel <20020122113102.29577.00000...@mb-cq.aol.com>, albina...@aol.com
(ALBINALI4) schreibt:

Quote
>Is this left out in Pascal for example in a statement like
>k=j+func(&j); with j being changed...! Does the standard specify how this
>will be evaluated exactly.

The standard specifies that the results are inpredictable when side effects
come in, as when j is changed in your example. The same rule applies to C.

When you are not sure of the order of evalutation, then you can split the
expression into multiple expressions, which then are evaluated in exactly the
given order, e.g.

k := j;
k := k + func(&j);

DoDi

Re:Pascal's Evaluation Order


ALBINALI4 heeft geschreven in bericht
<20020122113102.29577.00000...@mb-cq.aol.com>...

Quote
>Hi,

<snip>
Is this left out in Pascal for example in a statement like

Quote
>k=j+func(&j); with j being changed...! Does the standard specify how this
will
>be evaluated exactly.

>Thanks,
>Fahd

Now, this is exactly why I dislike C.

What does "k=j+func(&j)" stand for?
Couldn't the programmer just put another
"result:=result+j" in the function itself or
might that be not cryptic enough or too readable?

Most of the time these constructs add nothing
except confusion to the program. Not even efficiency.

The Pascal standard specification states that there
is no way the value of a variable in an expression
on the right hand side of an assignment-statement
will be changed.
(you will get compiler-errors for stupid C-like constructions)

I assume you are not referring to the precedence of standard
operators like /, +, or,. It is practically the same as in C.

Sending "j" as a var parameter to a function changes "j"
but it can not return because only one value (the function-
result) is returned. So the old (unchanged) value of "j" is
used in the expression.

To return the new value of "j" from a "function" you have to
use a procedure. Procedures do not exist in C, but
"void func()" comes close.

But in Pascal procedure-calls can never occur on the right
side of an assignment (or in an expression), they only occur
as "statements" on their own.

So: problem solved. No ambiguity in expressions in Pascal.

Huub.

Re:Pascal's Evaluation Order


Im Artikel <yze68.2487$A3.10...@typhoon.bart.nl>, "Huub van Dooren"
<hvdoo...@iae.nl> schreibt:

Quote
>Now, this is exactly why I dislike C.

Then you should dislike Pascal, too, because it offers all the things which you
deny in your comment.

IMO you should learn about the capabilities of Pascal first, before you post
such nonsense.

DoDi

Re:Pascal's Evaluation Order


VBDis heeft geschreven in bericht
<20020131184759.10450.00001...@mb-bk.aol.com>...

Quote
>Im Artikel <yze68.2487$A3.10...@typhoon.bart.nl>, "Huub van Dooren"
><hvdoo...@iae.nl> schreibt:

>>Now, this is exactly why I dislike C.

>Then you should dislike Pascal, too, because it offers all the things which
you
>deny in your comment.

>IMO you should learn about the capabilities of Pascal first, before you
post
>such nonsense.

>DoDi

Huh?
Please motivate.
Give the pascal equivalent of:

k=a=j==*p+i--&j++

Huub.

Re:Pascal's Evaluation Order


Im Artikel <6KF68.2804$A3.14...@typhoon.bart.nl>, "Huub van Dooren"
<hvdoo...@iae.nl> schreibt:

Give the types of the symbols of:

Quote
>Give the pascal equivalent of:
>k=a=j==*p+i--&j++

I know how to read C, and the above statement is invalid in C ;-)

DoDi

Re:Pascal's Evaluation Order


Quote
"VBDis" <vb...@aol.com> wrote in message news:20020203192255.04803.00000970@mb-cm.aol.com...
> Im Artikel <6KF68.2804$A3.14...@typhoon.bart.nl>, "Huub van Dooren"
> <hvdoo...@iae.nl> schreibt:

> Give the types of the symbols of:

> >Give the pascal equivalent of:
> >k=a=j==*p+i--&j++

> I know how to read C, and the above statement is invalid in C ;-)

Invalid in C++ too!

If someone near me wrote code like that, well,
I'd make HIM an INVALID, too!

Rufus

Re:Pascal's Evaluation Order


Rufus V. Smith heeft geschreven in bericht
<3c5eecff$2$10784$4c410...@reader0.ash.ops.us.uu.net>...

Quote

>"VBDis" <vb...@aol.com> wrote in message

news:20020203192255.04803.00000970@mb-cm.aol.com...
Quote
>> Im Artikel <6KF68.2804$A3.14...@typhoon.bart.nl>, "Huub van Dooren"
>> <hvdoo...@iae.nl> schreibt:

>> Give the types of the symbols of:

>> >Give the pascal equivalent of:
>> >k=a=j==*p+i--&j++

>> I know how to read C, and the above statement is invalid in C ;-)

>Invalid in C++ too!

>If someone near me wrote code like that, well,
>I'd make HIM an INVALID, too!

>Rufus

Thanks for nothing, guys!
Nothing beats an ego-tripping programmer.

Huub.

Re:Pascal's Evaluation Order


Quote
> Thanks for nothing, guys!
> Nothing beats an ego-tripping programmer.

> Huub.

well what the ____ (the F word) does k=a=j==*p+i--&j++ supose to mean?

ANY C statement CAN be translated in Borland Pascal! how many Pascal
statements it would require? one for about each '=' sign. that's what
i like C for, you don't type so many word's even if ya don't use
crypts. the rule of evaluation in C is simple, just go from right to
left, step by step.
the thing i lOvE in Borland Pascal is that B. Pascal is a razor sharp
lang. there's no other match. BP is simple and sharp enuff to get to
single assembler instruction. l00k :

  asm
     mov        ah,0Ch
     mov        al,[col]
     mov        cx,[x]
     mov        dx,[y]
     mov        bx,[1]
     int        10h
  end;

pure assembler + use of Pascal variables.
i think that the above translated to C(++), would look like this :

  _AH = 0x0C;
  _AL = Col;
  _CX = x;
  _DX = y;
  _BX = 0x01;
  geninterrupt (0x10);

now, does not that look like some cryptic shit? if there is another,
more assembly like way to write it in C please let me know. it'll make
me like C even more.

Vasko

Re:Pascal's Evaluation Order


To Vasko.

Thank you for your serious reply.

Vasko Altiparmakov heeft geschreven in bericht ...

Quote
>well what the ____ (the F word) does k=a=j==*p+i--&j++ supose to mean?

Never mind it's meaning, is it valid C or not?

Quote
>ANY C statement CAN be translated in Borland Pascal! how many Pascal
>statements it would require? one for about each '=' sign. that's what
>i like C for, you don't type so many word's even if ya don't use
>crypts. the rule of evaluation in C is simple, just go from right to
>left, step by step.

Yes, you are right.
The point I am trying to make is:

(I found my 15 year old C book)

1. Regarding "k=j+func(&j)" :
What is the point of using "j+" in an expression when that same "j"
is already a parameter to a function in that same expression.
To me, this "feels" the same as:

a=( some very complex expression with function calls);
a=a+b   /* followed by a very simple one */

But the original poster only used this example to point out that
both the function result as well as a modified value of "j" were returned.

2. Not every expression on a single line in C can be written as the same
"one line" Pascal expression.
But as you pointed out: Every C-fragment can be translated in Pascal
or assembler or Fortran or even Cobol. The latter may take some time
to translate and type in the source  :-)

3. Pascal has more rigid rules than C, resulting in less ambiguity.
- No pre- or post-incrementing/decremting operators.   --i  j++
- No operator-overloading:   * means multiply or pointer to
- No combined assignment operators: *=  += /=
(Also meaning less creative expressions, but: win some, loose some)
I am NOT starting a C versus Pascal war here. The language you feel
most comfortable in is mostly a matter of personal taste.

Quote
>the thing i lOvE in Borland Pascal is that B. Pascal is a razor sharp
>lang. there's no other match. BP is simple and sharp enuff to get to
>single assembler instruction. l00k :

>  asm
>     mov        ah,0Ch
>     mov        al,[col]
>     mov        cx,[x]
>     mov        dx,[y]
>     mov        bx,[1]
>     int        10h
>  end;

>pure assembler + use of Pascal variables.
>i think that the above translated to C(++), would look like this :

>  _AH = 0x0C;
>  _AL = Col;
>  _CX = x;
>  _DX = y;
>  _BX = 0x01;
>  geninterrupt (0x10);

>now, does not that look like some cryptic shit? if there is another,
>more assembly like way to write it in C please let me know. it'll make
>me like C even more.

Looks cryptic, but is useful and makes sense.

In BP you could have written:

uses Graph;
putpixel(x,y,Col);           {nearly as fast; more readable}

Quote
>Vasko

Thanks, anyway.

Greetings. Huub.

Re:Pascal's Evaluation Order


"Huub van Dooren" <hvdoo...@iae.nl> wrote in message news:U1j88.3814$A3.19768@typhoon.bart.nl...

Quote

> Rufus V. Smith heeft geschreven in bericht
> <3c5eecff$2$10784$4c410...@reader0.ash.ops.us.uu.net>...

> >"VBDis" <vb...@aol.com> wrote in message
> news:20020203192255.04803.00000970@mb-cm.aol.com...
> >> Im Artikel <6KF68.2804$A3.14...@typhoon.bart.nl>, "Huub van Dooren"
> >> <hvdoo...@iae.nl> schreibt:

> >> Give the types of the symbols of:

> >> >Give the pascal equivalent of:
> >> >k=a=j==*p+i--&j++

> >> I know how to read C, and the above statement is invalid in C ;-)

> >Invalid in C++ too!

> >If someone near me wrote code like that, well,
> >I'd make HIM an INVALID, too!

> >Rufus

> Thanks for nothing, guys!
> Nothing beats an ego-tripping programmer.

Sorry, I thought the invalid/invalid pun was funny at the time.

Re:Pascal's Evaluation Order


"Huub van Dooren" <hvdoo...@iae.nl> wrote in message
news:tmC88.3988$A3.20872@typhoon.bart.nl...
...

Quote

> 3. Pascal has more rigid rules than C, resulting in less ambiguity.
> - No pre- or post-incrementing/decremting operators.   --i  j++
> - No operator-overloading:   * means multiply or pointer to
> - No combined assignment operators: *=  += /=

This can make C source code more terse, but it doesn't necessarily lead to
better compiled code. That's down to better C compilers.

Quote
> (Also meaning less creative expressions, but: win some, loose some)

To some extent it's a matter of opinion, but "creative expressions", where
it means programs get hard to read, and ambiguous so that they only work on
one compiler/OS/computer, is about as appealing to me as "creative
accounting".

FP

Go to page: [1] [2]

Other Threads