What could help to transition towards a Pascal without semicolon would be to have a compiler switch to forbid the use of else instead of otherwise in a case statement and to forbid empty statements so that people would need to write begin end in these rare occurences.Here are some thoughts. The exception you mentioned creates an inconsistency, sometimes the semicolon would be required, other times it wouldn't be.
After that, we could transition to an optional semicolon, and then to remove it completely.
An exception could be kept though to have multiple statements on one line.
What do you think?
procedure aa(j:integer); begin end;
procedure bb; begin end;
procedure cc; begin end;
function yy(j:integer):integer; begin end;
function zz(j:integer):integer; begin end;
begin
aa(yy(zz(33));
bb();
cc();
end.
Fatal: Syntax error, ")" expected but ";" found
Now, the call to aa is unbalanced. Without a semicolon, bb would probably be parsed as part of the parameter construction of aa, and errors would be something like missing operator for on the bb line.Omitting the semicolon would mean that a linebreak implicitly finishs the statement, so for the error handling this wouldn't be more difficult, but of course it results in a lot of places in the compiler code that needs adaption.
While now you getQuoteFatal: Syntax error, ")" expected but ";" found
Omitting the semicolon would mean that a linebreak implicitly finishs the statement, so for the error handling this wouldn't be more difficult, but of course it results in a lot of places in the compiler code that needs adaption.
Because of the linebreak-sensitivity a new concept for multiline statements would be needed. In Fortran (90?) e.g. the character '&' is used to tell the compiler that the statement will go on in the next line.
But to remain constructive, let's forget that for now;
But to remain constructive, let's forget that for now;
Pun intended?
The main problem of dropping the semicolon is the loss of backwards-compatibilty. Moreover, I don't see a useful point in replacing a single character by "begn end".
This is why if you really mean this, you need to build a proof of concept. For everything, including errorhandling.Just in case you overlooked, I'm not the TE and I wouldn't even vote for such a change. Some time before I had a different view on it, but compatibility is really essential.
I also want to reiterate the error handling point again, but I whipped up an example as illustration. Each time you change fundamental (block-statement structure) of the language you have to rethink error handling.Ok now that you gave an example I see what you are thinking about. Line endings.
I also want to reiterate the error handling point again, but I whipped up an example as illustration. Each time you change fundamental (block-statement structure) of the language you have to rethink error handling.Ok now that you gave an example I see what you are thinking about. Line endings.
Well that's not a problem. Without semicolons this would be:bb would not be considered as a parameter in anyway. Following a ")" by an identifier is not a continuation of instruction, it is in implicit end of instruction.
Without semicolons it looks " naked". That will be forbidden in the USA.:D
You obviously missed the point - in "aa line" there is one more open parentheses than closed. Compiler will not be able to notice anything wrong in that line, and will treat bb as parameter of aa.Nope I understood the point. But as there is no comma, it will not be considered as the next parameter.
Nope I understood the point. But as there is no comma, it will not be considered as the next parameter.That makes statements "fragile" because one missing comma can change the semantics of the statement. Usually, and hopefully, the compiler will catch the error later, maybe 3 or 4 tokens later, when that missing comma ends up creating something that is not semantically valid.
Uh, and I do hope you wouldn't want line endings to be significant in any way.Why not? The line ending is quite intuitive for being the end of a statement.
Nope I understood the point. But as there is no comma, it will not be considered as the next parameter.
Pascal is as it is. It use semicolons to separate the declarations. Breaking the compatibility of billions of lines of code by changing this is not a good idea. If someone doesn't like semicolons, he/she better find another programming language!
Pascal is as it is. It use semicolons to separate the declarations. Breaking the compatibility of billions of lines of code by changing this is not a good idea. If someone doesn't like semicolons, he/she better find another programming language!
why to break compatibility? making it optional doesn't break any codeIt does have the potential to break code. The example given in a previous post
kotlin does that, just ignores the semicolonbut it has a different grammar that allows it (and may even be designed) to make the semicolon optional. Pascal's grammar relies on the semicolon to clearly establish the end of a statement.
why to break compatibility? making it optional doesn't break any codeIt does have the potential to break code. The example given in a previous postshows that the statement is semantically different if the semicolon after the "writeln(2)" is not there. I wish I could think of other examples but, none come to mind at this time but, that doesn't mean there aren't other cases like the one above.
My point is that, it is very dangerous to conclude the semicolon can be made optional in all cases without a careful analysis of the language's grammar. As previously stated, even if it can be done, the compiler's complexity will increase because it will have to infer where/when statements end which could definitely have an impact on its compilation speed. (a fast compiler is a very nice thing to have.)kotlin does that, just ignores the semicolonbut it has a different grammar that allows it (and may even be designed) to make the semicolon optional. Pascal's grammar relies on the semicolon to clearly establish the end of a statement.
No I think it doesn't break old code. Because you will not be removing the semicolon in old code.ok, that point is valid.
Also why not replace that odd else with something like "default " that's verbose as well.That would mean a version of Pascal that allows "else", "otherwise" and "default" for the same thing. That kind of stuff gives a strong impression that the language wasn't well thought out or, is driven by "Christmas tree design" (shiny feature!.. we'll hang it over here.)
Languages changes, evolves or die.Yes but, the evolution usually happens in ways that are significant and coherent with the essence of the language. A change that causes the compiler to be slower and emit even less precise error messages doesn't seem to be evolution in the right direction.
In fact you can already write otherwise instead of else. There you have your Christmas tree.Also why not replace that odd else with something like "default " that's verbose as well.That would mean a version of Pascal that allows "else", "otherwise" and "default" for the same thing. That kind of stuff gives a strong impression that the language wasn't well thought out or, is driven by "Christmas tree design" (shiny feature!.. we'll hang it over here.)
Pascal is as it is. It use semicolons to separate the declarations. Breaking the compatibility of billions of lines of code by changing this is not a good idea. If someone doesn't like semicolons, he/she better find another programming language!Is it that you are afraid of loosing unity and that you would rather reject people to preserve it?
Languages changes, evolves or die.
I don't think that the semi colon is a problem and I don't think it is useless either, as argumented by others. But to the opposiste I would even like it to be allowed in a specific case:
You see before the else.
In Pascal, ; is the block or statement separator, what you ask is to introduce whitespace and line separators in the language that is a quadratic complexity added to the parser.... Very good idea...
To err is human, but to really mess things up, you need a computer.
I don't think that the semi colon is a problem and I don't think it is useless either, as argumented by others. But to the opposiste I would even like it to be allowed in a specific case:I suppose that would be possible by considering the semicolon as required statement terminator. But then it would not just be allowed in this case but mandatory.
You see before the else.
That escalated quite quickly. This is just a discussion, relax. 8-)Languages changes, evolves or die.
And most mutations die.
That escalated quite quickly. This is just a discussion, relax. 8-)Languages changes, evolves or die.
And most mutations die.
I don't think that the semi colon is a problem and I don't think it is useless either, as argumented by others. But to the opposiste I would even like it to be allowed in a specific case:
You see before the else.
In Pascal, ; is the block or statement separator, what you ask is to introduce whitespace and line separators in the language that is a quadratic complexity added to the parser.... Very good idea...
It was meant to note that in evolution few changes make it long term. IOW "Not every changement is an improvement". Sometimes even only after quite a while (e.g. when circumstances change and the change lead to overspecialisation).Ok I understand where you're coming from. I would agree in general with what you say.
you haveI am not sure I understand where you define the semicolon here.
That's perfectly LL(1), in no way more than one lookup is necessary.
In this case of course, it is not a random mutation and I would love to have a semicolon-less code. That's why I am entertaining this discussion, to get insights from others and not be alone thinking about it.
you haveI am not sure I understand where you define the semicolon here.
That's perfectly LL(1), in no way more than one lookup is necessary.
It introduces complexilty because of the dangling else .... That is not complex, isn't it... Try to adapt a Pascal grammar...<SIGH >:D>
So I would like to retract my earlier advise to try modify fcl-passrc, but advise you to whip up some relevant examples (also think about errorhandling, so also wrong/non compilable tests!) and try to use some parser generator tool to get some grammar that is roughly working on these examples to flesh out the details and get a starting point.I understand the grammar approach, though as I explained before, I guess I would rather have a token approach. It is quite simple to have a preprocessor that adds semicolon. That could leave the compiler untouched.
So I would like to retract my earlier advise to try modify fcl-passrc, but advise you to whip up some relevant examples (also think about errorhandling, so also wrong/non compilable tests!) and try to use some parser generator tool to get some grammar that is roughly working on these examples to flesh out the details and get a starting point.I understand the grammar approach, though as I explained before, I guess I would rather have a token approach. It is quite simple to have a preprocessor that adds semicolon. That could leave the compiler untouched.
That escalated quite quickly. This is just a discussion, relax. 8-)Languages changes, evolves or die.
And most mutations die.
:D
I don't know of any phobia of that kind ; though I suppose it is possible ;
@marcov: Indeed an IDE tool could the the instant conversion between the view and the code file. Though I don't know how to do such a tool.
I mean, I never used semicolons to write Spanish or English, but I know these was often used in the past. Modern texts does't use them or most people don't know how to use them.
This is what happens when the first language people learn is Python. It's ugly. Trust me.
This is what happens when the first language people learn is Python. It's ugly. Trust me.
Maybe we are thinking about different things. I'm not talking about a new "language" or anything, just an edit menu option in lazarus to check a block of selected code and add missing semicolons. Just like e.g. tabs-to-spaces, which implementation could be followed.Ah ok no I was thinking of making an editor where the semicolon do not appear, yet they are saved in the file for the compiler.
But our Pascal doesn't use ';' as an end of statement but a separator between statements. It's the problem.It separates code blocks It is no problem at all....
I believe there are ways to deduce where to put the semicolons. This can be deduced from the tokens that begins and ends lines.Well, adapt the grammar. Can you provide proof for these "ways"? Because I can prove it will not work. (disprove)
I am talking about having the Source editor showing a code without semicolons. Either by converting it on the fly, or indeed by a compiler option. Such option need not a new compiler but could just enable a preprocessor that adds the semicolons.
I believe there are ways to deduce where to put the semicolons. This can be deduced from the tokens that begins and ends lines.
I believe there are ways to deduce where to put the semicolons. This can be deduced from the tokens that begins and ends lines.Getting rid of semicolons is not that simple. For instance
It is also worth noting that while parsing Pascal is usually reasonably fast, your preprocessor, if it were a full parser, it would definitely result in perceptibly slower compile times.
I would like to say that the question posed by circular is interesting, I believe that any proposal that aims to discuss a possible greater spread of Lazarus/FPC is to be considered. Simplifying code writing might be useful for this purpose.
Really? Did you forgot I done a IUP binding for Pascal and code is still on my github?
Did you ever see I compared Pascal with Basic except I said Basic code is twice as long as Pascal and I don't like long code?
Did I said anything about other language except the news about Ada++ I found on Phoronix? Sorry if it's insult you but I only want to know how people react to such news and you are too sensitive. Reread the first post on my Ada++ thread, I said: "I will just put it here and don't said anything", did I post anything after that?
Did you have proof I'm a troll? Please show it. Otherwise don't make such claim, so everyone would ignore me and all of my threads asking for help.
If you want, just delete my thread about Ada++.
I was talking about the tokens like "+" etc. I was kind of expecting the end of lines not to be tokens but discarded as whitespace. Is it possible to know the position of a token? If not then that would make it difficult to add the preprocessor in the current compiler stack.QuoteI believe there are ways to deduce where to put the semicolons. This can be deduced from the tokens that begins and ends lines.There are no tokens in pascal compilers for that. The scanner filters them already out before producing the real tokens.
Your "semicolon paster" would end up declaring untyped parameters every time there is a comma missing between "var" parameters resulting in one parameter being untyped and the remainder being passed by value instead of reference and, the worst part is, the programmer would not have a clue that the missing comma resulted in a definition with a completely different meaning than what he/she intended.No no I am talking about semicolons for instruction ending. And in fact I am ok for semicolons within the line.
Here are some thoughts. The exception you mentioned creates an inconsistency, sometimes the semicolon would be required, other times it wouldn't be.
I would like to say that the question posed by circular is interesting, I believe that any proposal that aims to discuss a possible greater spread of Lazarus/FPC is to be considered. Simplifying code writing might be useful for this purpose.
If the feature results in increased maintenance (in this case increased complexity of the parser) for no real gain (really, you are all arguing about semicolons?!), then no it's not even remotely worth to be considered.
I was talking about the tokens like "+" etc. I was kind of expecting the end of lines not to be tokens but discarded as whitespace. Is it possible to know the position of a token? If not then that would make it difficult to add the preprocessor in the current compiler stack.QuoteI believe there are ways to deduce where to put the semicolons. This can be deduced from the tokens that begins and ends lines.There are no tokens in pascal compilers for that. The scanner filters them already out before producing the real tokens.
Though for an external tool, that's not complicated to add a way to determine tokens location.
No no I am talking about semicolons for instruction ending. And in fact I am ok for semicolons within the line.Even only in the case of instruction ending, it's not only the compiler that uses the semicolons to figure things out. Tools like "codetools" and the "Code Explorer" (and possibly others) in the IDE, are almost certain to depend on semicolons in one way or another to do their job (I haven't looked at their implementation, therefore I cannot be precise about this.)
@PascalDragon
Hello.
I'm sorry for the misunderstanding caused by me.I would like to say that the question posed by circular is interesting, I believe that any proposal that aims to discuss a possible greater spread of Lazarus/FPC is to be considered. Simplifying code writing might be useful for this purpose.
If the feature results in increased maintenance (in this case increased complexity of the parser) for no real gain (really, you are all arguing about semicolons?!), then no it's not even remotely worth to be considered.
It is possible that I did not explain myself clearly enough, but in the rest of my post (which you did not report) I explained that I am absolutely opposed to the abolition of the ";".
In fact, I took the example of how difficult it is, sometimes, to identify the true cause of errors within codes written in VB.net (language that does not use the ";") and the risk that pascal would take if it eliminated the ";".
I also suggested, in case it was necessary, the use of an external tool to convert the code from VB.pascal (proposed by circular) to FPC.
The introductory speech (which you have reported) is a general consideration, I think circular had a positive purpose in proposing it.
For me, an interesting proposal should be discussed even if I do not approve of the content of the proposal itself.Otto.
I believe that any proposal that aims to discuss a possible greater spread of Lazarus/FPC is to be considered.
It's not only about this specific topic (the semicolons), but your generalisation I don't agree with:I respect your opinion.I believe that any proposal that aims to discuss a possible greater spread of Lazarus/FPC is to be considered.
I wanted to point out that a proposal can be taken into account without the need to accept it. The most important thing is, in my opinion, to discuss the cause that led a programmer to ask that specific question. Discussing the cause might be helpful for other programmers to discuss their opinions. Not all of us have had the same kind of training, so discussing basic topics could help someone clarify some aspect of programming in FPC that doesn't match the one in the language he had previously learned.
Since a compiler error needs that info. But the scanner (which includes the FPC internal preprocessor) and the parser are intertwined. It would be a colossal job to detangle them, create a new level inbetween to splice the external preprocessor into etc.I see so I would not try that then.
Keep in mind the external tool would be extremely complicated since any manipulations must keep the token stream equivalent or the errors would be on the a different line and number. Study how the C preprocessor works etc etc.That's ok because it is just appending a token at the end of the line.
And before to even attempt such thing (and then again, already purely hypothetical), you would have to demonstrate the concept using an own fork of FPC first, before one starts rearranging the whole parser.I am not requesting that any action be taken as of now.
Anyway, I think this is a dead end. If you really want something like that, you're better off crafting some language based on syntax concepts of a language that has no need for statement terminators like python or basic.I disagree, I think there is potential for an alternate source editor and for tools that convert text code from and to semicolon-less.
Sendo, dunque, uno principe necessitato sapere bene usare la bestia, debbe di quelle pigliare la golpe e il lione; perché il lione non si defende da’ lacci, la golpe non si defende da’ lupi. Bisogna, adunque, essere golpe a conoscere e’ lacci, e lione a sbigottire e’ lupi. Coloro che stanno semplicemente in sul lione, non se ne intendano. Non può, pertanto, uno signore prudente, né debbe, osservare la fede, quando tale osservanzia li torni contro e che sono spente le cagioni che la feciono promettere. E se gli uomini fussino tutti buoni, questo precetto non sarebbe buono; ma perché sono tristi, e non la osservarebbono a te, tu etiam non l’hai ad osservare a loro.
I've always seen reasons given in rejections. So they were evaluated/considered.Marcov you are certainly right and I agree with you.
Just as users request get the response, the users must also trust the developers in their judgement. :)
I disagree, I think there is potential for an alternate source editor and for tools that convert text code from and to semicolon-less.Putting aside my doubts about the feasibility, it seems really extreme to invest that much time and work to accomplish such a trivial and, not particularly useful, goal of getting rid of semicolons in Pascal.
I will see if I have the time to try it out.
Yeah, that wasn't even close to what I was talking about. I give up on this forum.:'(
Same code without useless semicolons:
an additional character would need to be provided to support multi-line statements.I am not sure, but I can see one case where this may be useful. For example if you make a call on the next line:
The semicolon is useless most of the time. Though sometimes, it makes a difference. So I am thinking that we could simply avoid these cases and remove the semicolon completely. It seems that many people agree, though we can make it a compiler option so that anyone is free to do as they want.I have not read all the comments to your idea so my comment might be superfluous, but I have two remarks.
The only language that really qualifies for not needing a statement separator or terminator is assembly.
I was speaking in terms of explicit separators. I consider the line ending an implicit separator if it is treated as such by the compiler; it is impossible to forget a line ending by the programmer unless you put two statements on one line which really doesn't make sense: mov ax, 1 mov dx, 2 :(The only language that really qualifies for not needing a statement separator or terminator is assembly.
Note that (almost?) all assemblers do require that statements end (or is separated from the next) with a line end, and assembly sintax is (usually) even stricter than Pascal, which is why it's so (relatively) easy to write one. Not really a good example, is it? ;D
Because Go was mentioned in this discussion, it also uses the semicolon as a statement separator. While optional, the Go compiler inserts it where omitted, which IMO is not a good approach.
2. The semicolon as a statement terminator is very useful, both from a readability and from a practical point of view. Consider the following BASIC example without semicolon support:This was fixed in VB.Net by guessing line continuation. Now you very rarely need write explicit line continuation. So you see it is not either one or the other.... and the same with semicolon support:
In fact the only case where there is a need for a terminator/separator, is when it would make sense to start a new instruction on the new line. In the example you provided, the + symbol cannot start a statement, so there is no ambiguity.Maybe not in this particular example, but that would require the programmer to know where and where not to break a statement to the next line. What if you break it before an identifier? It would add a LOT of complexity to the compiler to distinguish between an assignment, procedure call or line continuation.
I have several likenesses in behaviour and account data, some of which I have commented on here. If you insist, I'll pass it all on to my co moderators for judgement in a query about account deletion.
Or you can just own up to it, and get a fair last chance, just because I also overstepped a bit in a bad mood.
Despite you deleted your account the last time when I pmed you with warnings, I should still have gone that way instead of posting in the thread out of the blue. Mea culpa, and a last chance for you if you are honest about it.
I hope someday someone capable will pick up my idea and actually turn it to real. A Pascal without Lazarus. But I think it will never happen.It is certainly not likely to be pursued with any enthusiasm on a forum which is dedicated in both name and purpose to Lazarus.
I hope someday someone capable will pick up my idea and actually turn it to real. A Pascal without Lazarus. But I think it will never happen.
Did anyone ever think about using Pascal to code GTK+ alongside with Glade and not through the LCL abstraction?
p.s. fpgtk before fpgui, even.
A Pascal without Lazarus. But I think it will never happen.It has already happened. FPC doesn't need Lazarus in any way to produce an object file.
Quotep.s. fpgtk before fpgui, even.
Hu, fpgtk, what is that, no mention in wiki?
https://wiki.freepascal.org/IDE
fpc/trunk/packages/fpgtk/src/pgtk/pgtk.pp
Is it still maintained and compilable (first shot was not out-of-the-box)?
Give 2 filenames :
First the object description file
Second the Pascal unit filename
All of the things you mentioned, do not work. Some abandoned. Some hopelessly outdated. These broken things can't be used to hide the fact we are so dependent on the LCL.Don't be surprised. Nowadays GUIs are huge and it is a lot of work to just keep things up-to-date. Windows is just one part. GTK development is going so fast, it is hard to keep up, especially by people who do not get paid for it.
I have done my work to do GUI without the LCL. Thanks to the Windows API and a wrapper library I ported from C. But I still have to use Lazarus as IDE because there is no real alternative.
Here is a somewhat exaggerated example from the project I'm working on, but it illustrates the issue very well:In fact this expression is not a problem. It depends a bit of the rules using to continue lines, but using the rules I proposed before, it would work, because there are tokens that either need something afterwards or something before. I have put each case as comments in the code.
@Munair,
An unrelated question, I see your function uses the function name to assign it a return value. Do you plan to implement something like "result" in FPC in your compiler to optionally use that instead of the function's name ?
Here is a somewhat exaggerated example from the project I'm working on, but it illustrates the issue very well:In fact this expression is not a problem. It depends a bit of the rules using to continue lines, but using the rules I proposed before, it would work, because there are tokens that either need something afterwards or something before. I have put each case as comments in the code.
What do you think of C++/M2 return <x>?Great suggestion.
Saves on typing, but isn't a pseudo function like syntax. (IOW syntax that isn't used anywhere else)
p.s. keep in mind that Pascal parsers generally only have one token lookahead.
BTW, SharpBASIC also has only one look-ahead character.
BTW, SharpBASIC also has only one look-ahead character.
But does it require line continuations ? Because then the line separator acts as a semicolon in pascal, so that would not be comparable.
I invite you to develop a compiler that supports the rules you suggest. Do you have any idea how much more complicated and *less* efficient an expression parser becomes having to consider line endings? Not to mention the lexer!That might be the case, though your example doesn't work, and you're not admitting it. :P
I had a look at FPC compiler and wow it would need a lot of refactoring.Aside from the things you found. Removing the semicolon from the Pascal syntax would significantly increase the amount of work the compiler would have to perform in order to emit anything that would be a half-way decent error message.
I invite you to develop a compiler that supports the rules you suggest. Do you have any idea how much more complicated and *less* efficient an expression parser becomes having to consider line endings? Not to mention the lexer!That might be the case, though your example doesn't work, and you're not admitting it.