Am I did it wrong all the time? lazarus / 8-Other ---------------------------------------------------------------------- guest65278 · 2020-02-23 12:46 https://everything2.com/title/When+to+use+a+semicolon+in+Pascal I used to think it's just like C. p/s: I come here from Modula-2, I come to Modula-2 from Oberon-07 and I come to Oberon-07 from C. ---------------------------------------------------------------------- lucamar · 2020-02-23 13:20 In Pascal the semicolon is a statement separator, unlike in C and similar where it's a terminator. That means that you only need to add it if the next element is another statement, but  frankly speaking most people don't ever bother: we just add a semicolon as a matter of course ... with one exception: before an else, where it's actually forbidden. The reason for that "careless" actitude (beyond laziness ) is that if you later add statements you don't have to go back to see whether the statement before the insertion point have a semicolon or not; you already know it has. With the exception, of course, of pre-"else" statements, but then you'll have to add a "begin..end" block if there'are more than one statement, so no much problem there either. And yes, adding a semicolon where it's not needed introduces an empty statement but, so what? Empty statements cause very little (if any) delay in parsing and produce no code, so better safe than sorry HTH. ---------------------------------------------------------------------- guest65278 · 2020-02-23 14:04 @lucamar: that's the reason why I left Oberon. Pascal and Modula-2 are more tolerant. Oberon is too strict. The code is compact but most of the time I found myself stuck figuring out why my code doesn't compile, it's usually because missing of an END or missing of a semicolon somewhere but after checked the code serveral times I still can't figure out where it is. Interfacing with C library is a tricky hack depends on each compiler. You can't even write a shared lib. Oberon might found it place on very small embedded device programming but I found myself totally unproductive with it. I miss the way C use semicolon, it's stupidly simple but just works. Luckily, Pascal doesn't care about empty statement so it's almost just like C. ---------------------------------------------------------------------- lucamar · 2020-02-23 14:19 I like Oberon; it reflects the distilled wisdom gained through the design and building of Pascal and Modula, and it ruthlesly hacks away the dead wood and over-complication added to those through the years. Unfortunately there is no mainstream, production-ready, multiplatform compiler and tools for it (AFAIK) and it has even less users than Pascal, so there'll probably never be one. Note that the strictness of Oberon plays in its favor: almost any sintatic error will have just one reason and one solution, and most parsers will stop at the correct point (or thereabout) where the error ocurred. ---------------------------------------------------------------------- guest65278 · 2020-02-23 14:31 Quote from: lucamar on February 23, 2020, 03:19:59 pmI like Oberon; it reflects the distilled wisdom gained through the design and building of Pascal and Modula, and it ruthlesly hacks away the dead wood and over-complication added to those through the years. Unfortunately there is no mainstream, production-ready, multiplatform compiler and tools for it (AFAIK) and it has even less users than Pascal, so there'll probably never be one. Note that the strictness of Oberon plays in its favor: almost any sintatic error will have just one reason and one solution, and most parsers will stop at the correct point (or thereabout) where the error ocurred. Our poor man just want his code to compile to see if it works  Joking aside. There are many compiler for Oberon: Vishap Oberon (VOC): it's Oberon-2, but understands Oberon-07, too. OBNC: it's an Oberon-07 compiler, very small and just works. The above compiler translate Oberon code into C source and use a C compiler to get the final binary. Note: I found VOC's generated C source is more readable than ONBC but both of them produce very readable C source. There is Oberonc, too. This guy compiles into Java bytecode and will work on any JVM >= 1.8  I use CudaText for coding Oberon. Case sensitive sucks, though. Here is my workaround: only use the Modula-2 lexer as it will ask you to choose between each lexer everytime you open a .mod file if you install the Oberon lexer, too. Always use uppercase, use Auto Replace plugin to overwrite proper function and library name for convenient. e.g: OUT.STRING will be overwrite to Out.String automatically by the Auto Replace plugin ---------------------------------------------------------------------- howardpc · 2020-02-23 14:34 Quote from: lucamar on February 23, 2020, 02:20:57 pmIn Pascal the semicolon is a statement separator, unlike in C and similar where it's a terminator. That means that you only need to add it if the next element is another statement, but  frankly speaking most people don't ever bother: we just add a semicolon as a matter of course ... with one exception: before an else, where it's actually forbidden. A minor amendment: ...with one exception: before an else in an if statement, where it's actually forbidden. Before an else in a case construct the separating semicolon is actually required unless there is a begin/end block immediately preceding the else, when the semicolon after the 'end' is optional, at least in FPC. ---------------------------------------------------------------------- julkas · 2020-02-23 15:09 Compiler Construction - The Art of Niklaus Wirth ftp://ftp.ssw.uni-linz.ac.at/pub/Papers/Moe00b.pdf ---------------------------------------------------------------------- guest65278 · 2020-02-23 15:27 Quote from: howardpc on February 23, 2020, 03:34:13 pmQuote from: lucamar on February 23, 2020, 02:20:57 pmIn Pascal the semicolon is a statement separator, unlike in C and similar where it's a terminator. That means that you only need to add it if the next element is another statement, but  frankly speaking most people don't ever bother: we just add a semicolon as a matter of course ... with one exception: before an else, where it's actually forbidden. A minor amendment: ...with one exception: before an else in an if statement, where it's actually forbidden. Before an else in a case construct the separating semicolon is actually required unless there is a begin/end block immediately preceding the else, when the semicolon after the 'end' is optional, at least in FPC. This sound complicated. Why not let life easier? ---------------------------------------------------------------------- Otto · 2020-02-23 15:40 Hello everyone. Quote from: lucamar on February 23, 2020, 03:19:59 pmNote that the strictness of Oberon plays in its favor: almost any sintatic error will have just one reason and one solution, and most parsers will stop at the correct point (or thereabout) where the error ocurred. It would be interesting to add a new mode to the future version of the FPC (perhaps FPC 4.0) that would allow us to have this feature. However, I have already been told that the developers of FPC are too busy. Greetings. Otto. ---------------------------------------------------------------------- lucamar · 2020-02-23 16:03 Quote from: Otto on February 23, 2020, 04:40:27 pmIt would be interesting to add a new mode to the future version of the FPC (perhaps FPC 4.0) that would allow us to have this feature. I don't think it'll be possible: it depends almost exclusively on the sintax of the language. Any parser to has to continue parsing until it can't go further; it just happens that Oberon has an even stricter grammar than Pascal, so it stops (generally) at the most minor "infraction", while the Pascal parser may continue making (or tryng to make) sense for several (or a lot of) lines more. ---------------------------------------------------------------------- Otto · 2020-02-23 16:42 @ lucamar Hi, I imagined something like that. The more I study the source code of Lazarus IDE, the more I appreciate many of the decisions that have been made; so I understand your opinion well. Greetings. Otto. ---------------------------------------------------------------------- guest65278 · 2020-02-23 17:16 @lucamar, @Otto: Please, I don't want Free Pascal to be like Oberon at all. I have stuck hours without success figuring out why my code didn't compile, the compiler just said it's missing an END. You know? I didn't missed any END. It's just because I forgot to place a semicolon and it's refused to compile my code and said again and again RETURN unexpected, expecting END or IDENT unexpected, expecting END... Write some code in Oberon-07 and compile with OBNC and you will know the misery! ---------------------------------------------------------------------- 440bx · 2020-02-23 18:48 Quote from: julkas on February 23, 2020, 04:09:51 pmCompiler Construction - The Art of Niklaus Wirth ftp://ftp.ssw.uni-linz.ac.at/pub/Papers/Moe00b.pdf That paper was a genuine pleasure to read. A load of simplicity and common sense.  Thank you. ---------------------------------------------------------------------- winni · 2020-02-23 19:28 Analogous: "Programming languages ​​are developed by someone alone, not by committees." Niklaus Wirth ---------------------------------------------------------------------- MaxCuriosus · 2020-02-23 23:40 I don't quite understand nov97's drift. I use plenty of begin, end, semi-column,etc. even when not absolutely necessary. It helps me clarify the structure of my programs, and help the parser. ---------------------------------------------------------------------- lucamar · 2020-02-24 09:21 Quote from: MaxCuriosus on February 24, 2020, 12:40:14 amI don't quite understand nov97's drift. I use plenty of begin, end, semi-column,etc. even when not absolutely necessary. It helps me clarify the structure of my programs, and help the parser. That's precisely his point: Oberon compilers barf on a lot of that extra "candy". For example, this a perfectly legitimite statement in Pascal but not in Oberon: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i begin  begin begin    ;;;;;;;;; DoSomething; ;;;;;;;;;  end; end;end; Also Oberon has a much stricter syntax with respect to "begin" and "end": for example, there are places where there can be no "begin" but the block must be terminated with an "end"; and so on. All of this means that we, "lazy" Pascal programmers, may have unspected (and somewhat baffling) problems when writing Oberon code. ---------------------------------------------------------------------- guest65278 · 2020-02-24 09:45 Quote from: MaxCuriosus on February 24, 2020, 12:40:14 amI don't quite understand nov97's drift. I use plenty of begin, end, semi-column,etc. even when not absolutely necessary. It helps me clarify the structure of my programs, and help the parser. I said about another language, Oberon, but not Pascal. ---------------------------------------------------------------------- MarkMLl · 2020-02-24 10:38 Quote from: nov97 on February 23, 2020, 04:27:20 pmThis sound complicated. Why not let life easier?  It all boils down to what can be parsed. An if then is a particular kind of statement, an if then else is a different kind. The parser relies on being able to find either ; or else, and it uses that distinction to decide what it's looking at and how to continue: any suggestion that that should be "fixed" is a non-starter which is quite simply not worth discussing. A number of the core developers and long-term users are, like myself, "refugees" from Modula-2 and are keenly aware of what's known as the "dangling else problem" and other Pascal shortcomings. It would be desirable to change the syntax to fix these, but it's quite simply not feasible since it would break backward-compatibility with Delphi and cause enormous problems to those of us who maintain older code... some of which dates back to Turbo Pascal and even older compilers. One possibility would be a per-unit directive which mandated the Modula-style if then else end rather than the Pascal-style if then else. But that still wouldn't help people who refused to take the time to learn the fundamental syntax, or both lacked the background to understand why certain things are the way they are and refused to accept the guidance of those with more experience. My own feeling is that Oberon is too restrictive, and while it was designed to be a systems programming language- and used as such by Wirth's research group- it is too inclined towards language "purity" at the expense of practical usability. Gutknecht wrote a paper on why "the best" languages generally weren't adopted, my own answer to that is that while a "pure" language might appear "obvious" to its designers it can be totally obscure to the remainder of the community. Having noticed it discussed a few days ago, I would like to wrap up by mentioning Vector Pascal which is probably the last significant research effort using the Pascal syntax. My own feeling is that there are things which can usefully be learned from it, in particular that it would be desirable to distinguish between concatenation of strings and (dynamic) arrays and iterative addition of their elements. MarkMLl ---------------------------------------------------------------------- PascalDragon · 2020-02-24 13:03 Quote from: lucamar on February 23, 2020, 05:03:00 pmQuote from: Otto on February 23, 2020, 04:40:27 pmIt would be interesting to add a new mode to the future version of the FPC (perhaps FPC 4.0) that would allow us to have this feature. I don't think it'll be possible: it depends almost exclusively on the sintax of the language. Any parser to has to continue parsing until it can't go further; it just happens that Oberon has an even stricter grammar than Pascal, so it stops (generally) at the most minor "infraction", while the Pascal parser may continue making (or tryng to make) sense for several (or a lot of) lines more. A parser doesn't have to continue parsing. E.g. pas2js stops after the first error. It's just rather convenient if the parser tries to recover cause other errors can be reported in the same run as well. Though this increases the "dangers" of false errors if the code in question depends on the first error. ---------------------------------------------------------------------- MarkMLl · 2020-02-24 13:49 Quote from: PascalDragon on February 24, 2020, 02:03:09 pmA parser doesn't have to continue parsing. E.g. pas2js stops after the first error. It's just rather convenient if the parser tries to recover cause other errors can be reported in the same run as well. Though this increases the "dangers" of false errors if the code in question depends on the first error. The paper by XXXXXXXXXXX that somebody cited earlier specifically talks about Oberon only trying to advance beyond a syntax error to a limited extent: QuoteRecursive  descent  parsing  requires  the  grammar  of  a  language  to  be  LL(1),  that means it must be possible to analyze the language top-down from left to right with a single  lookahead  symbol.  Whenever  there  is  an  alternative  in  the  grammar,  the lookahead  symbol  must  lead  the  way  and  tell  the  compiler  which  alternative  to select. [...] Given  the  fact  that  computers  become  faster  and  faster,  it  is  not  necessary  any more  to  find  all  errors  in  a  single  compilation.  If  a  compilation  takes  less  than  a second, it is acceptable to find just some errors, correct them, and then compile the program  again  to  find  the  remaining  errors.  Thus  the  Oberon  compiler  does  not synchronize  with  the  followers  of  every  nonterminal  symbol  but  selects  a  few synchronization points in the grammar where recovery is particularly easy and safe.These  synchronization  points  are  the  beginning  of  a  statement,  a  declaration  or  a type  where  symbols  such  as  "IF",  "WHILE",  "TYPE"  or  "RECORD"  are  expected.These  symbols  are  considered  particularly  safe,  because  they  are  unlikely  to  been countered  in  the  wrong  context. I love to read comments from people who say that "such-and-such behaviour in a parser is silly", and then go on to explain how it can be improved without breaking things. Regrettably, that's an extremely rare combination. MarkMLl ---------------------------------------------------------------------- lucamar · 2020-02-24 14:22 Quote from: PascalDragon on February 24, 2020, 02:03:09 pmA parser doesn't have to continue parsing. Which is why said it may continue parsing, not that all of them always do so (and most don't when they find a fatal error). ---------------------------------------------------------------------- guest65278 · 2020-02-24 16:43 Quote from: MarkMLl on February 24, 2020, 11:38:54 amMy own feeling is that Oberon is too restrictive, and while it was designed to be a systems programming language- and used as such by Wirth's research group- it is too inclined towards language "purity" at the expense of practical usability. Gutknecht wrote a paper on why "the best" languages generally weren't adopted, my own answer to that is that while a "pure" language might appear "obvious" to its designers it can be totally obscure to the remainder of the community. Having noticed it discussed a few days ago, I would like to wrap up by mentioning Vector Pascal which is probably the last significant research effort using the Pascal syntax. My own feeling is that there are things which can usefully be learned from it, in particular that it would be desirable to distinguish between concatenation of strings and (dynamic) arrays and iterative addition of their elements. MarkMLl Also notice Oberon use garbage collector and most of the compiler depends on the boehm-gc library (the JVM based one doesn't, of course). I found it's weird to type POINTER TO something without the ability to FREE something. Oberon has the NEW keywork, but no FREE or DISPOSE or something like that. Check here: https://miasap.se/obnc/oberon-report.html#sec3 Er, I don't think we should learn anything from Vector Pascal. This compiler allow you to type code in Unicode and the code will look very weird. Check it manual here: https://sourceforge.net/projects/vectorpascalcom/files/ ---------------------------------------------------------------------- PascalDragon · 2020-02-25 08:48 Quote from: lucamar on February 24, 2020, 03:22:30 pmQuote from: PascalDragon on February 24, 2020, 02:03:09 pmA parser doesn't have to continue parsing. Which is why said it may continue parsing, not that all of them always do so (and most don't when they find a fatal error). Ehm, no, you said this: Quote from: lucamar on February 23, 2020, 05:03:00 pmAny parser to has to continue parsing until it can't go further You didn't say that it may continue until it can't go further... ---------------------------------------------------------------------- lucamar · 2020-02-25 10:41 Yes, an unfortunate election of words on my part Though I did say "[...] while the Pascal parser may continue making (or tryng to make) sense [...]". But you're right; not my more brilliant post, is it? ---------------------------------------------------------------------- Thaddy · 2020-02-25 12:37 Hm.. annoyed by those last two experts. Pascal is designed to be a single pass compiler. We know that is not the case but the principle holds at most a one look ahead..... One of you is actually helping to destroy that.. to my joy... ";" ---------------------------------------------------------------------- guest65278 · 2020-02-25 16:15 Quote from: MarkMLl on February 24, 2020, 11:38:54 amA number of the core developers and long-term users are, like myself, "refugees" from Modula-2 and are keenly aware of what's known as the "dangling else problem" and other Pascal shortcomings. It would be desirable to change the syntax to fix these, but it's quite simply not feasible since it would break backward-compatibility with Delphi and cause enormous problems to those of us who maintain older code... some of which dates back to Turbo Pascal and even older compilers. MarkMLl I quote you only want to note that even though GNU Pascal was dead but GNU Modula-2 is still alive and kicking. Their latest release is based on gcc 8.2.0. They provided packages for Debian 9 but I'm using Debian 10 so I have to build from source. The process took more than one hour but everything was straight forward, just follow their document and you will be OK. As I have said I set up CudaText to code Modula-2. But I finally migrated here because there is too little to zero documents for Modula-2. I only found a simple tutorial on the net. Modula-2 confused me a lot because there are so many dialects and a lot of incompatibility between them. I downloaded PIM books pdf version but can't stand the poor quality scanned text. And there is no way to found anything about the ISO dialect. So finally I'm here. Abandoned both Modula-2 and Oberon. ---------------------------------------------------------------------- PascalDragon · 2020-02-26 08:41 Quote from: Thaddy on February 25, 2020, 01:37:08 pmHm.. annoyed by those last two experts. Pascal is designed to be a single pass compiler. We know that is not the case but the principle holds at most a one look ahead..... One of you is actually helping to destroy that.. to my joy... ";" That is precisely why I hate Delphi's generics syntax. It implodes the single token look ahead if you have something like if SomeVarOrType might be many tokens away. In the FPC syntax however single token look ahead is working perfectly fine: if specialize SomeVarOrType>Jedi Code Formatter>>Format Setting>>Clarify>>Transform>>Add begin and end to single statements” simply press "Ctrl-D" to switch from (e.g.) Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i if a = 5 then    inc(a)  else    dec(a)    to Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  if a = 5 then  begin    Inc(a);  end  else  begin    Dec(a);  end;       I hope it helps someone. Otto.