"If I could export one feature of Go into other languages, it would be interfaces."
I have written an extremely compact (~10000 lines) Pascal compiler (https://github.com/vtereshkov/xdpw) for Windows. Initially built with Free Pascal, it is now self-hosting.I've looked at your compiler in the past. I see you've been busy :)
XD Pascal for Windows 0.12
Copyright (c) 2009-2010, 2019-2020, Vasiliy Tereshkov
Compiling system.pas
Compiling BooleanConstantExpression.lpr
An unhandled exception occurred at $00416D6A:
EStackOverflow: Stack overflow
$00416D6A
$00416FA7
$00416FA7
$00416FA7
$00416FA7
$00416FA7
$00416FA7
$00416FA7
$00416FA7
$00416FA7
$00416FA7
$00416FA7
$00416FA7
$00416FA7
$00416FA7
$00416FA7
$00416FA7
By the way, while you're at it, why not remove the ";" ?Is the semicolon so annoying for you? Even more than begin...end instead of (now common) {...} ? :)
You could try to develop that idea further with a compile to memory option or so and a good demonstration (integrate in old dev pascal ide or so?).I'll definitely do it if I see any signs of practical interest from the community. Now many people like my project as a curious museum piece, but not as a tool for their daily tasks.
For bits and pieces like the bug that 440bx found you could try to harvest the FPC testsuite (and maybe pas2js has tests somewhere too for the fcl-passrc parser)The only test suite I regularly run is the ISO Pascal Acceptance Test by S. A. Moore (with some Borland-specific changes). Once I tried to run a huge GNU Pascal test suite, but it mostly contains tests for some rare features (like "modules" from ISO Extended Pascal). So my compiler has successfully compiled just about 600 tests of 5000 (Delphi compiled about 900). I have to look at the FPC test suite.
By the way, while you're at it, why not remove the ";" ?Is the semicolon so annoying for you? Even more than begin...end instead of (now common) {...} ? :)
I'll think of it, but the semicolon cannot be completely removed - it can be made optional. The compiler source will have them anyway, since I need to keep it compatible with Delphi/FPC.
You could try to develop that idea further with a compile to memory option or so and a good demonstration (integrate in old dev pascal ide or so?).I'll definitely do it if I see any signs of practical interest from the community. Now many people like my project as a curious museum piece, but not as a tool for their daily tasks.
If not for compatibility, you'd be better off implementing a Modula2 than a Pascal anyway. Even if you stick with Wirthian. So keeping compatibility is paramount IMHOIf I dare abandon compatibility, I'll probably make a completely different language. Modula-2 and Oberon still require that declarations be separated from statements, so that I cannot declare a variable where I really need it. They still don't have type inference, returning multiple values from a function, the "+=" operator, the generalized for statement, etc.
If I dare abandon compatibility, I'll probably make a completely different language. Modula-2 and Oberon still require that declarations be separated from statements, so that I cannot declare a variable where I really need it. They still don't have type inference, returning multiple values from a function, the "+=" operator, the generalized for statement, etc.
As for the testsuite, it might get you more borland oriented source pieces. But probably it is a mish mash of the various dialects support for FPC (turbo/delphi/iso/objective pascal). so might require some sorting out. It certainly won't be ready to run.Thank you. It is not well-suited to my compiler, but anyway it has already helped me find and fix one more bug :)
That's a suggestion as I was thinking of writing a parser to make Pascal easier. Removing the semicolon was part of it.By the way, while you're at it, why not remove the ";" ?Is the semicolon so annoying for you? Even more than begin...end instead of (now common) {...} ? :)
I'll think of it, but the semicolon cannot be completely removed - it can be made optional. The compiler source will have them anyway, since I need to keep it compatible with Delphi/FPC.
Or I am missing something?
- Dangling else?Give me an example as I have done, please. That's too easy otherwise.
- multiline statements?You don't need a semicolon for that :
- error handling?Please expand.
- compatibility ? And if you change this, why try being compatible or even pascal at all?That's just polarizing the debate and you are aware of it. I like Pascal, there are just some things that can be improved.
Or I am missing something?
- Dangling else?
- multiline statements?
- error handling?
- compatibility ? And if you change this, why try being compatible or even pascal at all?
Hi!the pascal syntax did not support classes either they where introduced with delphi 1 it did not support objects, advenced records and a list of other features too. That's a week excuse of an argument don't you think?
I repeat myself but:
The else in the case statement is and was a bad idea.
It was introduced by Turbo Pascal.
The Pascal syntax is otherwise.
Just abolish the else in case.
Winni
Getting rid of the semicolon in Pascal is not a good idea. The reason is, a semicolon tells the compiler a statement has ended. Without the semicolon, the compiler has to figure out a statement has ended using context, that alone is likely not possible in all cases and, even if possible, it would complicate the compiler's code.- error handling?
Please expand.
Use otherwise with case to make meaning clear.I agree. I used that example to show that getting rid of semicolons in Pascal is not as simple as it first seems to be. Removing the "else" option from the "case" statement would definitely break backwards compatibility which is obviously not desirable.
Quote- compatibility ? And if you change this, why try being compatible or even pascal at all?That's just polarizing the debate and you are aware of it. I like Pascal, there are just some things that can be improved.
I think the most dangerous form of 'dangling else' is when it's inside the case statement. The output of the example below depends on whether there is a semicolon before else or not.Indeed. In fact, that would be the only compelling argument for keeping the semicolon.
var a: integer = 1; begin case a of 1, 2: if a = 2 then writeln(2); else writeln(1); end; end.
The else in the case statement is and was a bad idea.Oh I did not know I could use otherwise here. That feels safer indeed. :)
It was introduced by Turbo Pascal.
The Pascal syntax is otherwise.
Just abolish the else in case.
Another example that comes to mind which I personally use all the time is this:Interesting trick. Though you can also do:that way I can ensure the code can handle the condition without having to create a test case for it, which in some cases can be very difficult and/or time consuming, to ensure the code works. By optionally inserting that semicolon after the "then" I can activate the code.
if somecondition then {$IFDEF FORCE_CONDITION} ; {$ENDIF} begin <statements to handle the condition> end;
This whole subthread is polarizing, making minor syntax details seem to be the center of the world.You're trying the mirror effect now.
The point is and remains if you "improve" it (and that is a very subjective word), it is no longer Pascal, and Modula2 is not that far from Pascal, but then with better blockstructure. See e.g. Oxygene with its changing procedure to method for objects etc.I am not forcing the idea. We could vote on it and that could be a compiler switch.
You are either compatible, or not. Even if you label "not compatible" as "improved" to make it sound nicer.There you go again polarizing.
But I'd leave this the same for compatibility's sake, and if it is that important for you, and it is that easy/automatic, enhance an editor to do it for you.I have been thinking about it.
Note that the nested IF dangling else only matters to keep the scanner part more context free https://en.wikipedia.org/wiki/Dangling_elseIn fact I don't see how it changes anything because the ; is not allowed anyway before else.
Interesting trick. Though you can also do:Yes but, that takes two lines. With the one I use, I can have the directive in one line in the editor's buffer and insert very quickly in all the "if" statements whose statements I want to test and, removing it if necessary only requires deleting one line. Faster, more efficient. Long live the semicolon. :)
{$IFNDEF FORCE_CONDITION} if somecondition then {$ENDIF} begin <statements to handle the condition> end;
Yes but, that takes two lines. With the one I use, I can have the directive in one line in the editor's buffer and insert very quickly in all the "if" statements whose statements I want to test and, removing it if necessary only requires deleting one line. Faster, more efficient. Long live the semicolon. :):D I can see why you would not want to enable the compiler directive semicolon-free. :)
This whole subthread is polarizing, making minor syntax details seem to be the center of the world.You're trying the mirror effect now.
Nope I did not intend to make a whole subthread or make it the center of the world. It just seems that people care and have interesting things to say about it.
I am not forcing the idea. We could vote on it and that could be a compiler switch.
QuoteYou are either compatible, or not. Even if you label "not compatible" as "improved" to make it sound nicer.There you go again polarizing.
QuoteBut I'd leave this the same for compatibility's sake, and if it is that important for you, and it is that easy/automatic, enhance an editor to do it for you.I have been thinking about it.
QuoteNote that the nested IF dangling else only matters to keep the scanner part more context free https://en.wikipedia.org/wiki/Dangling_elseIn fact I don't see how it changes anything because the ; is not allowed anyway before else.
I created a new topic:
https://forum.lazarus.freepascal.org/index.php/topic,49153.0.html
Nope. Simply two standards. Everybody but you has hidden agenda, your actions are indisputable. I'm wondering what "effect" you'll think up for this.I have no idea what you're talking about.
If you accept the basis premise that it is a serious problem. The thread is terribly light on this.I don't consider it to be a serious problem. I am just talking freely.
I'm not polarizing. It is a fact. Unless you want to accuse other pascal compilers not accepting the dialect anymore as polarizing. Naughty, naughty parsers.Judgements are not the way to go my friend.