0

like in Algol 68 an if statement ends with fi and a case statement ends with esac , so what are some readability problem other than the reserved words doesn't really make sense in English.

Any suggestions would be appreciated

nicael
  • 18,550
  • 13
  • 57
  • 90
Rami
  • 61
  • 4

2 Answers2

4

There's not really a readability problem, it's simply something you get used to, and after some experience the problems falls out of the process. Similar to how many Lisp users "don't see" the parentheses. They simply don't stand out in the general case for the experienced reader.

You have to recall the time of Algol, notably the "68" part, as in 1968.

The bright side of the fi, esac, and od is that they clearly indicate what kind of block they're terminating, and they do it with a single token.

esac is no less clear than }, which is a meaningless bracket until you know otherwise. The {} have the benefit of consistency, while less wordy than Pascals begin - end generic block sequence.

Finally, consider how dominant the English language is in computer language design, and while folks who don't speak english may have some initial issues with the languages, that clearly passes over time.

So, it's a short hurdle that falls away quickly with use.

Will Hartung
  • 115,893
  • 19
  • 128
  • 203
  • Can't you define a (side effecting) procedure named esac with no arguments? If you can, its invocation would be indistinguishable from the closing of the case block without considering the context. Also, I very much doubt that any algol68 compiler would issue a warning if you just use esac as a variable without assigning it to something. – user1666959 Nov 17 '13 at 04:35
  • Note: In English Algol68's reverent case statement reads `case ~ in ~ out ~ esac`... In Soviet Algol68 this reads `выб ~ в ~ либо ~ быв`. c.f. "[GOST 27974-88 - АЛГОЛ 68](http://vak.ru/lib/exe/fetch.php/book/gost)" – NevilleDNZ Nov 17 '13 at 21:32
  • 2
    Algol 68 distinguishes keywords (typically printed in boldface, or "stropped" in source code (either by using uppercase IF or "dot-stropping": .IF) and identifiers, the latter being often restricted to lowercase, but with whitespace allowed. Therefore there is no problem distinguishing the keyword ESAC and the identifier esac.Names of modes (types) and operators have the same syntax as keywords, but can be defined by the programmer, but within this set of words, the keywords are reserved, so it would not be valid to make a MODE ESAC=STRUCT(INT a, INT b). – LHP Jan 21 '14 at 10:22
  • 1
    Also note that the language defines short forms: "**if** if **then** then **elif** elif **then** elifthen, **else** 3 **fi**" can be written "(if | then |: elif | elifthen | 3 )". Likewise "CASE i IN 1,2,3 OUSE j IN 4,5,6 OUT 9 ESAC" can be written "(i|1,2,3|:j|4,5,6|9)". Neville has already mentioned localized keywords. – LHP Jan 21 '14 at 10:32
1

What readability issues? None.

The 'bracketing' approach removes ambiguity that is otherwise resolved by fiat.

For example, in the syntax of Algol 60, in

 if B1 then if B2 then S2 else S3

it is ambiguous which 'then' the 'else' pairs with; is it effectively like this?

 if B1 then begin if B2 then S2 else S3 end

or like this?

 if B1 then begin if B2 then S2 end else S3

To resolve the problem, there is an explicit rule saying it's the former case. That simply is not a problem in Algol 68. The two cases are syntactically distinct.

 if B1 then if B2 then S2 else S3 fi fi

and

 if B1 then if B2 then S2 fi else S3 fi

This is no harder to read than the use of parentheses in arithmetic expressions to determine the meaning.

Languages such as C and Java, which have regressed to the 'begin/end' style (through written as braces { }) suffer in readability by comparison.

user13784117
  • 1,124
  • 4
  • 4