ways to avoid begin-end’s?

[Weiss]

I am thinking, there are quite often times when there are only two statements between begin-end encapsulation. Wouldn’t it be neat if I could say something like

Code: Pascal  [Select][+][-]

1.  if x=1 then x:=2 AND DoSomething(x)

rather than currently

Code: Pascal  [Select][+][-]

1. if x=1 then
2.      begin
3.        x:=2;
4.        doSomething(x)
5.      end;
6.  

or maybe there is some other neat ways of combining statements

[MarkMLl]

If there's a single statement then you can omit the begin-end. If there isn't then you can't, and trying to change things will make the language into something that isn't Pascal: isn't going to happen.

Now if an assignment also had a value, which is the situation in C and also in Pascal's predecessor ALGOL-60, then you could do something like

Code: [Select]

if x=1 then
  (x:=2 = 2) AND DoSomething(x);

However (a) that is at least as cumbersome as having an explicit begin-end and (b) that kind of chained assignment becomes incredibly problematic when a language supports any form of automatic casting (e.g. an expression which probably returns an 8-bit value is assigned to a 32-bit variable).

Wirth's newer languages such as Modula-2 required the end in all cases:

Code: [Select]

IF x=1 THEN
  x:=2;
  DoSomething(x)
END;

In that case it would be possible to argue for "syntactic sugar" e.g.

Code: [Select]

IF x=1 THEN:
  x:=2;

But I am really not convinced that that would be a good thing.

MarkMLl

[marcov]

No!

[cdbc]

Hi
The pascal language entails 'begin .. end', if it doesn't, it's not pascal.
...And I can imagine a debugging nightmare with 'Italian cuisine'-code like this:

if x=1 then x:=2 AND DoSomething(x)

Not to mention the confusion regarding bit/logical operators...
Nah, I like my begin-ends, they make it easy(ier) to spot mistakes 
Right..., /now/ you can call me a 'conservative old fart' 
Regards Benny

[Weiss]

ok. Point taken. I agree, I was wrong. In retrospect, it was probably begin-end’s that made me like Pascal in first place.

[Kays]

ways to avoid begin-end’s?

Opening a can of… spaghetti: It is called goTo.

Code: Pascal  [Select][+][-]

1. label
2.         9999;
3. begin
4.         if x <> 1 then goto 9999;
5.                 x := 2;
6.                 doSomething
7.  
8. 9999:
9.         ;

Yeehaw, no (extra) begin … end anymore.

[Weiss]

using my example above, begin-end could be avoided by passing argument like so

Code: Pascal  [Select][+][-]

1. if x=1 then doSomething(2);

[Thaddy]

I am thinking, there are quite often times when there are only two statements between begin-end encapsulation. Wouldn’t it be neat if I could say something like

Code: Pascal  [Select][+][-]

1.  if x=1 then x:=2 AND DoSomething(x)

But that is already legal assuming that DoSomething is a function that returns an ordinal value. 

[dbannon]

....
But that is already legal assuming that DoSomething is a function that returns an ordinal value. 

Yes, to my surprise, it compiles. That means the compiler sees x:=2 as something that returns an ordinal value ? But not (x:=2) ?

Code: Pascal  [Select][+][-]

1. if x=1 then (x:=2) AND DoSomething(x); // does not compile

Davo

[Weiss]

however, something like

Code: Pascal  [Select][+][-]

1. if X=1 then X:=2 and i

does compile, and, like Thaddy mentioned, if doSomething is a function

Code: Pascal  [Select][+][-]

1. function doSomething : integer
2. begin
3. writeln('What Thaddy says goes');
4. end;

then this

Code: Pascal  [Select][+][-]

1. if x=1 then x:=2 and doSomething

compiles and runs fine, prints on screen.

 

[Weiss]

unreal

[440bx]

That means the compiler sees x:=2 as something that returns an ordinal value ? But not (x:=2) ?

The compiler sees:

Code: Pascal  [Select][+][-]

1. if x=1 then x:= (2 AND DoSomething(x));

It doesn't see the assignment as an operation that is separate from the "and".  It sees (as it should) whatever is right of the assignment as a statement.  integer AND integer is a valid statement therefore x := integer and integer (result from the function) is perfectly valid and really, totally run of the mill (though that may not be apparent at first sight.)

[Khrys]

That means the compiler sees x:=2 as something that returns an ordinal value ? But not (x:=2) ?

The compiler sees:

Code: Pascal  [Select][+][-]

1. if x=1 then x:= (2 AND DoSomething(x));

It doesn't see the assignment as an operation that is separate from the "and".  It sees (as it should) whatever is right of the assignment as a statement.  integer AND integer is a valid statement therefore x := integer and integer (result from the function) is perfectly valid and really, totally run of the mill (though that may not be apparent at first sight.)

Better make sure  DoSomething  doesn't just return some garbage from the stack. Throw in an  Exit(not 0)  and enjoy abusing the syntax, I guess...

[440bx]

Better make sure  DoSomething  doesn't just return some garbage from the stack. Throw in an  Exit(not 0)  and enjoy abusing the syntax, I guess...

I believe that for that definition of "DoSomething" the compiler emits a note or warning stating that the function isn't assigned a result (something which is not a good thing regardless of how the function is used.)

Just for the record, it is not syntactic abuse to have a statement such as "x := <some integer> and SomeFunction();" SomeFunction could simply be a function that returns the correct mask to use in that situation.  Quite run of the mill stuff.

[MarkMLl]

ok. Point taken. I agree, I was wrong. In retrospect, it was probably begin-end’s that made me like Pascal in first place.

It was a fair question, and the discussion has highlighted the ways in which even apparently innocuous "features" of a language can get messy.

Chained assignments, automatic type conversion, confusion between logical and bitwise operations...

Considering this reading of your example

Code: [Select]

    if x=1 then x:= (2 AND DoSomething(x));

the real question is whether DoSomething() returns an integer or a boolean. If it's an integer then that AND might work... but then the compiler could reasonably ask itself whether the sizes are compatible. If it's a Boolean it shouldn't work, but there's a chance of things going wrong if the compiler tries to promote DoSomething()'s result to an integer. So in either case that literal 2, which is clearly numeric but hasn't been explicitly given a type, /should/ at least result in a warning which the user /should/ take note of.

MarkMLl