Recent

Author Topic: Syntax curiosity  (Read 8435 times)

Zvoni

  • Hero Member
  • *****
  • Posts: 2317
Re: Syntax curiosity
« Reply #30 on: September 13, 2019, 02:47:53 pm »
I agree with Thaddy.

The "ElseIf" i know from VisualBasic (Classic Version 6, not Dot Crap!) is a way to narrow down the consequences if the initial Condition is not met.
"If Condition Then
Consequence1
ElseIf Condition2 Then
Consequence2
End"

In a "Standard" If-Then-Else construct something like a=4, A=7, A=123456
"If a=1 Then
Consequence1
Else
Consequence2
End"
Consequence2 would be executed for all values a<>1

with the "ElseIf" i can narrow down the filter for which Consequence2 should fire.

But in that case i'd rather use a "Case of"-Statement, which is alo available in VisualBasic
"Select Case a
Case 1
Consequence1
Case 4
Consequence2
Case 5
Consequence3
Case Else
NukeWhiteHouse
End Select"
And no, no arguing about Syntax-Beauty now :-)
Agree with Thaddy: Use "Case"
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad

munair

  • Hero Member
  • *****
  • Posts: 798
  • compiler developer @SharpBASIC
    • SharpBASIC
Re: Syntax curiosity
« Reply #31 on: September 13, 2019, 03:12:20 pm »
There is an important difference between IF and CASE:

Code: FreeBasic  [Select][+][-]
  1. if a = 1 then
  2.   ...
  3. elseif b = 1 then
  4.   ...
keep it simple

440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: Syntax curiosity
« Reply #32 on: September 13, 2019, 03:27:26 pm »
One slight advantage of case over if/then/else is that when repeated millions of times for the same operation, case is usually slightly faster.
Yes, because in the example you showed the compiler can create a jump table based on the variable's value but, a jump table can only be created when a single expression is compared against constants.  That's one of the very significant limitations of the case statement, the inability to compare one expression against another.

The other significant limitation that @Munair pointed out above is, a case statement can only handle a single expression.  If the logic depends on multiple expressions, a case statement cannot handle that.

COBOL's EVALUATE statement does not have those limitations and that statement really helps write some very clean, easy to understand and maintain code.  I know it won't happen but, it would be a very nice addition to the Pascal language ("Pascalized" of course.)

(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Zvoni

  • Hero Member
  • *****
  • Posts: 2317
Re: Syntax curiosity
« Reply #33 on: September 13, 2019, 05:46:36 pm »
In VB i could do this:
Select Case True
Case a=1
DoSomething1
Case b=3
DoSomethingElse
Case Else
KABOOM
End Select

Is there an equivalent in Pascal?
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad

dsiders

  • Hero Member
  • *****
  • Posts: 1052
Re: Syntax curiosity
« Reply #34 on: September 13, 2019, 06:00:00 pm »
In VB i could do this:
Select Case True
Case a=1
DoSomething1
Case b=3
DoSomethingElse
Case Else
KABOOM
End Select

Is there an equivalent in Pascal?

https://www.freepascal.org/docs-html/ref/refsu56.html
Preview Lazarus 3.99 documentation at: https://dsiders.gitlab.io/lazdocsnext

Zvoni

  • Hero Member
  • *****
  • Posts: 2317
Re: Syntax curiosity
« Reply #35 on: September 13, 2019, 06:04:04 pm »
Seems that‘s a no.
Pity, i do like it
And FWIW: In VB the Select Case is fallthrough!
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad

howardpc

  • Hero Member
  • *****
  • Posts: 4144
Re: Syntax curiosity
« Reply #36 on: September 13, 2019, 06:35:38 pm »
In VB i could do this:
Select Case True
Case a=1
DoSomething1
Case b=3
DoSomethingElse
Case Else
KABOOM
End Select

Is there an equivalent in Pascal?
Would this fit the bill?
Code: Pascal  [Select][+][-]
  1. program Project1;
  2.  
  3. {$mode objfpc}{$H+}
  4.  
  5.   procedure DoSomething1;
  6.   begin
  7.     WriteLn('DoSomething1');
  8.   end;
  9.  
  10.   procedure DoSomethingElse;
  11.   begin
  12.     WriteLn('DoSomethingElse');
  13.   end;
  14.  
  15.   procedure Kaboom;
  16.   begin
  17.     WriteLn('Kaboom');
  18.   end;
  19.  
  20.   procedure Choose(a, b: Integer);
  21.   begin
  22.     case (a = 1) of
  23.       True: DoSomething1;
  24.       False: case (b = 3) of
  25.                True: DoSomethingElse;
  26.                False: Kaboom;
  27.              end;
  28.     end;
  29.     WriteLn;
  30.   end;
  31.  
  32. var
  33.   a, b: Integer;
  34.  
  35. begin
  36.   a := 0;
  37.   b := 0;
  38.   Choose(a, b);
  39.   a := 1;
  40.   Choose(a, b);
  41.   a := 2;
  42.   b := 3;
  43.   Choose(a, b);
  44.   ReadLn;
  45. end.

Zvoni

  • Hero Member
  • *****
  • Posts: 2317
Re: Syntax curiosity
« Reply #37 on: September 13, 2019, 09:25:18 pm »
Howard, thx, but it‘s not of urgent importance to me right now, but i appreciate your effort
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Syntax curiosity
« Reply #38 on: September 19, 2019, 10:22:32 am »
The original Wirth syntax said:

After every then or else is exact one statement allowed. If there are more then one statement you have to enclose them with begin ... end;

Note that that wasn't a Wirth thing, that was an ALGOL-60 thing and there was also a variant like

a := if b: then c else d

which is all nice and orthogonal. But at some point before the ALGOL-68 standardisation process it was recognised that that syntax, no matter how elegant, was also susceptible to the dangling-else problem... note that I'm not calling it an ambiguity, but it's definitely a problem.

Wirth perpetuated the ALGOL-60 <single statement> form, when he could (and later did) fix it by adopting  if <condition> then <statement sequence> end  etc. He dropped the in-expression form despite this not being necessary (for the sake of consistency) until the statement form was fixed. And he introduced records etc. which had an explicit end, rather than themselves needing a begin...end pair. In short, whatever his reputation as a pragmatist, Pascal's syntax is messily inconsistent.

In ALGOL-60, begin...end was also used for the entire program (i.e. rather than program...end). Also variables were declared inside blocks rather than before them, the idea of moving declarations to before the  begin  would be all very well if it didn't preclude declaring temporary index variables for the  for  statement rather than leaving things as "this value becomes undefined".

So I'm sorry, but whatever the efforts of people over the years Pascal as defined by Wirth was flawed.

MarkMLl


MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: Syntax curiosity
« Reply #39 on: September 19, 2019, 01:21:45 pm »
But at some point before the ALGOL-68 standardisation process it was recognised that that syntax, no matter how elegant, was also susceptible to the dangling-else problem... note that I'm not calling it an ambiguity, but it's definitely a problem.
It's not a "problem", it is a consequence of the language not requiring explicit statement terminators for some constructs, e.g, if <statements> fi, or case <statements> esac.  The lack of explicit statement terminators is what causes the dangling else "problem".

he introduced records etc. which had an explicit end, rather than themselves needing a begin...end pair. In short, whatever his reputation as a pragmatist, Pascal's syntax is messily inconsistent.
There is no inconsistency, what there is, is the elimination of superfluous syntactic elements.  "record", "repeat" or "case" do not need begin/end pairs because they are by design <field>/<statement> containers, therefore requiring begin/end pairs in those statements would be superfluous and only add unnecessary clutter to the language.

So I'm sorry, but whatever the efforts of people over the years Pascal as defined by Wirth was flawed.
Every design has its own set of implications, that doesn't mean the design is flawed (though in some cases, it could.)

The Pascal language is very well designed. 
« Last Edit: September 19, 2019, 01:24:05 pm by 440bx »
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Syntax curiosity
« Reply #40 on: September 19, 2019, 01:31:22 pm »
But at some point before the ALGOL-68 standardisation process it was recognised that that syntax, no matter how elegant, was also susceptible to the dangling-else problem... note that I'm not calling it an ambiguity, but it's definitely a problem.
It's not a "problem", it is a consequence of the language not requiring explicit statement terminators for some constructs, e.g, if <statements> fi, or case <statements> esac.  The lack of explicit statement terminators is what causes the dangling else "problem".

Yes and no. It is the ambiguity of one or more statements.  Statement terminators are not necessary for if <cond> then <block> [else <block>]  simply because the block already is terminated with END. Then the else option is just one token lookahead.

Quote
The Pascal language is very well designed.

Which is probably why Wirth made the changes that Mark describes in his next languages Modula-*

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Syntax curiosity
« Reply #41 on: September 19, 2019, 03:32:43 pm »
The point I was trying to make was that dangling else is not an ambiguity as far as the language design was concerned: there is a robust rule which results in the parser always making the same choice when confronted by the same sequence of constructs.

But even though it's not a syntactic ambiguity, it is undoubtedly a problem in that it allows an inattentive (aka busy) or inexperienced user to write code which doesn't behave as he intended.

I for one would love it if that wasn't the case. I'd love it if something like the  if <conditional> then <single statement>  and so on form could be applied in all cases, and for consistency that includes data definition (after all, "Algorithms + Data Structures = Programs" implies that the notation should be orthogonal).

On the other hand, if you design a language to use  if <conditional> then <statement sequence> end  and so on, then you have some chance of implementing it with  begin <statement sequence> end  minimised to the point where a naive compiler can assume that it represents stackframe manipulation: something that generally isn't needed by simple structured program control flow.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

munair

  • Hero Member
  • *****
  • Posts: 798
  • compiler developer @SharpBASIC
    • SharpBASIC
Re: Syntax curiosity
« Reply #42 on: September 20, 2019, 07:27:25 pm »
But even though it's not a syntactic ambiguity, it is undoubtedly a problem in that it allows an inattentive (aka busy) or inexperienced user to write code which doesn't behave as he intended.

I can confirm that this is indeed the case with Pascal. However, we have to bear in mind the time that the language was developed. Compiler construction was in its infancy and over time significant and important improvements were implemented in successive languages that borrowed from the early greats such as Pascal. And here we touch upon the reason for developing new languages as the old ones almost always stick to their early definitions and rarely undergo syntax improvements that could lift them to modern standards.
keep it simple

munair

  • Hero Member
  • *****
  • Posts: 798
  • compiler developer @SharpBASIC
    • SharpBASIC
Re: Syntax curiosity
« Reply #43 on: September 20, 2019, 07:46:30 pm »
[Statement terminators are not necessary for if <cond> then <block> [else <block>]  simply because the block already is terminated with END. Then the else option is just one token lookahead.
Pascal doesn't have statement terminators. It has statement separators, which is not the same (yes, quite confusing). IMO statement terminators serve a better purpose in that they make it clear where a statement starts and where it ends, especially with (nested) IF blocks. Because in Pascal the semicolon is used as a statement separator, it often leads to null statements because (even experienced) programmers use it where it is not required. That is one issue I would like to tackle in a new Pascal-like language; it shouldn't leave any room for ambiguity.
keep it simple

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Syntax curiosity
« Reply #44 on: September 20, 2019, 08:46:04 pm »
However, we have to bear in mind the time that the language was developed. Compiler construction was in its infancy and over time significant and important improvements were implemented in successive languages that borrowed from the early greats such as Pascal. And here we touch upon the reason for developing new languages as the old ones almost always stick to their early definitions and rarely undergo syntax improvements that could lift them to modern standards.

Yes but: Wirth was on the ALGOL-68 standardisation committee, and ALGOL-68 fixed the dangling else problem using the solution eventually adopted by Wirth in Modula-2 (I'm not sure the standing of Modula(-1) with regards to this). It was also fixed in Ada, with which AIUI Wirth was involved as a consultant.

ALGOL-W had an ALGOL-60 style notation, and as such was susceptible to dangling else. Now Wirth might have been trying to avoid departing from ALGOL-60's gross syntax when he introduced Pascal, but in that case why did he- as a specific example- move the type in a variable declaration to the right of the name? If he broke the syntax by doing that for no obvious reason, why didn't he fix dangling-else at the same time since he undeniably knew that it was a problem?

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018