Re: [fpc-devel] Pascal Standard, and what we can do.
Yes, and why does an email/submission not in itself count as a vote? This isn't a 'threat' to the Free Pascal eco system, I'm trying to help! I hope the 'usuals' aren't thinking that I'm trying to stand up, go against, or similar? A standard can only help Free Pascal. It is up to us to have no bigger company take over the Standard. An Open Standard. I just want to raise Pascal to a level I think it deserves, and think this would be a great way for people to come together and voice their opinions/votes on specific features. I'm not asking for things like inline variables, etc. But I am asking that we stay up to date with coding functionality, and expect a certain result. It's the worst when someone comes up with an idea, adds it in FPC, and turns out people have issues against how it works, or the result wasn't as expected, etc. - Dennis On 2015-07-24 07:04 AM, Michael Van Canneyt wrote: On Fri, 24 Jul 2015, Den wrote: Actually, I recently proposed several changes to CSS, and I'm not a part of their working group. I can even track the status of it. Sure. Everyone can submit, why not ? Marco said vote :) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
Am 25.07.2015 um 18:36 schrieb Den: Yes, and why does an email/submission not in itself count as a vote? This isn't a 'threat' to the Free Pascal eco system, I'm trying to help! I hope the 'usuals' aren't thinking that I'm trying to stand up, go against, or similar? A standard can only help Free Pascal. It is up to us to have no bigger company take over the Standard. An Open Standard. I just want to raise Pascal to a level I think it deserves, and think this would be a great way for people to come together and voice their opinions/votes on specific features. Then just go ahead on working on a standard? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
2015-07-23 11:30 GMT+02:00 Sven Barth pascaldra...@googlemail.com: Sidenote/warning should you decide to work on the compiler now that you have a branch directory: adhere to the coding style used in the compiler even if you don't like it (I don't either ;) ), because that will definitely be a reason to refuse your code (you wouldn't be the first). I pointed this out before. For the greater good, we must to sacrifice oneself. ;) I'll start work at the end of August. I need to complete some work on sparta/lazarus branch. There is also wedding on my roadmap. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
2015-07-23 11:22 GMT+02:00 Michael Van Canneyt mich...@freepascal.org: The most convenient technological argument is compatibility with Oxygene. Well, that's a political argument, I think: we can choose to be not compatible with Oxygene :) (whether or not this would constitute suicide or not, is up for debate) To start any work on this I need to provide a few more patches related to Delphi compatibility. I would like to return to the subject in near future. The rest is in many cases a matter of taste. We can endlessly debate what is more readable :) Good. Now you're talking sense :) I look forward to your contributions! Nice to hear that. So I guess I don't need any fork ;) phew! -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Fri, 24 Jul 2015, Maciej Izak wrote: 2015-07-23 11:30 GMT+02:00 Sven Barth pascaldra...@googlemail.com: Sidenote/warning should you decide to work on the compiler now that you have a branch directory: adhere to the coding style used in the compiler even if you don't like it (I don't either ;) ), because that will definitely be a reason to refuse your code (you wouldn't be the first). I pointed this out before. For the greater good, we must to sacrifice oneself. ;) I'll start work at the end of August. I need to complete some work on sparta/lazarus branch. There is also wedding on my roadmap. Congrats, and that should be top priority :) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
In our previous episode, Den said: Actually, I recently proposed several changes to CSS, and I'm not a part of their working group. I can even track the status of it. You don't need to become part of FPC core to post bugs or requests either. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
Looks like I sparked quite a bit of interest! Perhaps we could work on a Standard instead of just on the Compiler itself? This gives people more of a look on what 'could' happen, instead of a Wiki where everyone can just edit. A system where voting is necessary, just like Standards from W3C, Khronos, etc, etc. A mailing list where people debate endlessly is not productive; we could have had a # of votes to see what should/should not be implemented, instead of a few key members deeming what's 'pascalish' or not. You may create that fork/branch now, but who knows who will actually end up merging it in? If they ever do. This is why we need a standard, so that there is NO wasted work, and people can get experience implementing things that are well documented first and know how they should act. *Plan first, Then Code*: I believe was said? ;) Then let us plan a standard, and what each feature should do, *then code*. I hope there is enough rally for this to happen! - Dennis Fehr On 2015-07-24 02:29 AM, Maciej Izak wrote: 2015-07-23 11:22 GMT+02:00 Michael Van Canneyt mich...@freepascal.org mailto:mich...@freepascal.org: The most convenient technological argument is compatibility with Oxygene. Well, that's a political argument, I think: we can choose to be not compatible with Oxygene :) (whether or not this would constitute suicide or not, is up for debate) To start any work on this I need to provide a few more patches related to Delphi compatibility. I would like to return to the subject in near future. The rest is in many cases a matter of taste. We can endlessly debate what is more readable :) Good. Now you're talking sense :) I look forward to your contributions! Nice to hear that. So I guess I don't need any fork ;) phew! -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
2015-07-24 12:13 GMT+02:00 Den cyr...@gmail.com: Looks like I sparked quite a bit of interest! Perhaps we could work on a Standard instead of just on the Compiler itself? This gives people more of a look on what 'could' happen, instead of a Wiki where everyone can just edit. A system where voting is necessary, just like Standards from W3C, Khronos, etc, etc. A mailing list where people debate endlessly is not productive; we could have had a # of votes to see what should/should not be implemented, instead of a few key members deeming what's 'pascalish' or not. You may create that fork/branch now, but who knows who will actually end up merging it in? If they ever do. This is why we need a standard, so that there is NO wasted work, and people can get experience implementing things that are well documented first and know how they should act. Simple/light voting system for that purpose integrated with proposal documents is also in my roadmap (something like https://gcc.gnu.org/projects/cxx1y.html but with users accounts/simple comments/voting system). Anyway I don't have any timeline for that. Maybe I'll do it sooner than any compiler change. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
In our previous episode, Den said: Looks like I sparked quite a bit of interest! Perhaps we could work on a Standard instead of just on the Compiler itself? This gives people more of a look on what 'could' happen, instead of a Wiki where everyone can just edit. A system where voting is necessary, just like Standards from W3C, Khronos, etc, etc. Neither is voting by uninformed people. People admitted to W3C and Kronos are a preselected group, not every internet user can vote directly on proposals. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Fri, 24 Jul 2015, Marco van de Voort wrote: In our previous episode, Den said: Looks like I sparked quite a bit of interest! Perhaps we could work on a Standard instead of just on the Compiler itself? This gives people more of a look on what 'could' happen, instead of a Wiki where everyone can just edit. A system where voting is necessary, just like Standards from W3C, Khronos, etc, etc. Neither is voting by uninformed people. People admitted to W3C and Kronos are a preselected group, not every internet user can vote directly on proposals. And even so, they mess up. XML was nice in theory, till namespaces came along. SOAP was nice in theory, till large companies messed with it. OAuth used to be simple, till version 2.0 come along. Just to name a few I came into contact with. Design by committee is rarely a good plan. I just keep hoping they will leave JSON and JSON-RPC and JSONSchema alone :( Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On 07/24/2015 12:13 PM, Den wrote: *Plan first, Then Code*: I believe was said? ;) Tee or beer / cupboard or fridge :-) :-) :-) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Fri, 24 Jul 2015, Den wrote: Looks like I sparked quite a bit of interest! Perhaps we could work on a Standard instead of just on the Compiler itself? This gives people more of a look on what 'could' happen, instead of a Wiki where everyone can just edit. A system where voting is necessary, just like Standards from W3C, Khronos, etc, etc. A mailing list where people debate endlessly is not productive; we could have had a # of votes to see what should/should not be implemented, instead of a few key members deeming what's 'pascalish' or not. You may create that fork/branch now, but who knows who will actually end up merging it in? If they ever do. This is why we need a standard, so that there is NO wasted work, and people can get experience implementing things that are well documented first and know how they should act. *Plan first, Then Code*: I believe was said? ;) Definitely. It will be good to have a working document. But an open source project is not a democracy; it is a meritocracy. If someone feels like doing one of your standards, it will happen, otherwise not. if you think otherwise, I think you are dreaming :) So a voting system is in my opinion redundant and probably counterproductive. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On 07/24/2015 12:13 PM, Den wrote: Perhaps we could work on a Standard instead of just on the Compiler itself? the normal RFC process ... -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
Actually, I recently proposed several changes to CSS, and I'm not a part of their working group. I can even track the status of it. - Dennis Fehr On 2015-07-24 06:02 AM, Marco van de Voort wrote: In our previous episode, Den said: Looks like I sparked quite a bit of interest! Perhaps we could work on a Standard instead of just on the Compiler itself? This gives people more of a look on what 'could' happen, instead of a Wiki where everyone can just edit. A system where voting is necessary, just like Standards from W3C, Khronos, etc, etc. Neither is voting by uninformed people. People admitted to W3C and Kronos are a preselected group, not every internet user can vote directly on proposals. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Fri, 24 Jul 2015, Den wrote: Actually, I recently proposed several changes to CSS, and I'm not a part of their working group. I can even track the status of it. Sure. Everyone can submit, why not ? Marco said vote :) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On 7/23/2015 12:21 AM, Michael Van Canneyt wrote: Oxygene is no longer pascal. It's just C# with pascal keywords. a pityful copy. If you want the features of C#, you should use C#, full stop. Exactly! I was first wondering if this would be a proper Pascal implementation to be used on top of .NET, but there is likely a reason why it isn't any longer part of Embarcadero's RAD Studio suite. Regarding inline declarations: Pascal is about bringing clear structure in your code. Plan first, code then. From this point of view there is no need for inline variable declarations. +1 That is what a lot of people that never really learned Pascal don't understand. And a lot of folks in the industry don't care about properly planned/designed software, just get something out fast, and deal with the problems later (aka constant delivery) Also, the location of variables is entirely irrelevant with an IDE like Lazarus. Press ctrl-c on a variable and Lazarus inserts it in the correct location, *as required by the language*. It is exactly because the Pascal language is so structured that Lazarus *can* do it. So: People who think they *need* inline variable declarations need in the first place to use another language than pascal or use a better IDE. +1 Pascal is much better in properly handling the scope of variables, giving you much better separation of local and global variables that most other programming languages. Just do it properly, without taking a temporary shortcut and you can eliminate a lot of potential problems in the future.. It is just a wish of people who think that 'anything goes', it has nothing to do with being more productive or being modern. +1 Ralf --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On 7/23/2015 2:45 AM, Michael Schnell wrote: On 07/22/2015 11:21 PM, Frederic Da Vitoria wrote: Declare before use has at least one technical advantage: it allows to make much faster compliers. Declare before use allows to compile in one pass, while compilers for languages like C need at least 2 passes. ??? ANSI C is a Declare before use language, too. No, not really. You can happily use variables and have them automatically assumed to be int, just as with any non-ANSI C compiler, just matter of pragma warning to be set. And you can define procedure/functions just about anywhere, with all the disadvantages of a clear schema as in Pascal (like changing the parameters in the .c file and forgetting to change the .h file). Ralf --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On 7/23/2015 1:35 AM, Maciej Izak wrote: If you want the features of pure pascal, you should use $MODE OBJFPC or TP or FPC, full stop. You can't stop me and others from introducing Oxygene flavored mode.Or if inside FPC team is will to block changes related to Oxygene flavored syntax, let me know and I will try to create fork of FPC compiler. Good luck to you! Ralf --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Thu, 23 Jul 2015, Sven Barth wrote: Am 23.07.2015 10:56 schrieb Michael Van Canneyt mich...@freepascal.org: I don't believe generics are the nec-plus-ultra of pascal (or any language). I documented them nonetheless (Sven: Ping ?) What? Who? Me?! Can't be! (My free time management is really screwed up since I've joined Tumblr -.- *sigh*) What is tumblr and how can I shut it down ? :) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
Marco van de Voort wrote: Typing was never the limiting factor in programming, Surely you're joking. Do you really claim that there has ever been any excuse for this sort of terseness, except for minimising keyboard work? A0: R := INSYMBOL; A1: IF F[S[I]] G[R] THEN GO TO A2; IF R = MARK THEN GO TO A9; I := J := I+1; S[I] := R; MOVE(NAME, V[I]); GO TO A0; A2: IF F[S[J-1]] = G[S[J]] THEN BEGIN J := J-1; GO TO A2 END; M := MTB[S[J]]; A3: IF PRTB[M] = 0 THEN BEGIN ERROR(5); GO TO EXIT END; N := J; And that's Wirth's code, by the way. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
In our previous episode, Mark Morgan Lloyd said: Typing was never the limiting factor in programming, Surely you're joking. No. Note that I mean notations that are mostly shorthand, not removal of primal language constructs. Do you really claim that there has ever been any excuse for this sort of terseness, except for minimising keyboard work? A0: R := INSYMBOL; A1: IF F[S[I]] G[R] THEN GO TO A2; IF R = MARK THEN GO TO A9; I := J := I+1; S[I] := R; MOVE(NAME, V[I]); GO TO A0; A2: IF F[S[J-1]] = G[S[J]] THEN BEGIN J := J-1; GO TO A2 END; M := MTB[S[J]]; A3: IF PRTB[M] = 0 THEN BEGIN ERROR(5); GO TO EXIT END; N := J; And that's Wirth's code, by the way. I'm not sure how this illustrates anything relating to shorthand language constructs. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
Am 22.07.2015 23:13 schrieb Maciej Izak hnb.c...@gmail.com: 2015-07-22 19:47 GMT+02:00 Sven Barth pascaldra...@googlemail.com: While I agree that type inference /might/ be useful I don't agree with inline variable declarations. One of the main points of Pascal is declare before use. While this is somewhat violated with Delphi compatible generics there one could at least argue that the specialized type is implicitly declared by the generic declaration... Regards, Sven Sorry Sven but I do agree with inline variable declarations. You don't have exclusive rights to dictate what is main point of Pascal (there is also Oxygene, SmartPascal). This is your opinion and this is not ultimate truth. There is also community with experienced users and big part of this community (especially around Delphi and Oxygene, not around FPC core development team :P) needs modern open source Pascal. This is not merely my opinion. Some people love Oxygene, and you can't tell that the Oxygene is not the Pascal. Any new construction will be non pascalish at first glance. No, that depends heavily on the specific construction. Mostly whether it was obviously just ripped from other languages like C# without giving a second thought about the way how things should be done in Pascal (for example attributes or Delphi's generics) or not (for example tuples in Oxygene). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
Am 23.07.2015 15:10 schrieb Michael Van Canneyt mich...@freepascal.org: On Thu, 23 Jul 2015, Sven Barth wrote: Am 23.07.2015 10:56 schrieb Michael Van Canneyt mich...@freepascal.org : I don't believe generics are the nec-plus-ultra of pascal (or any language). I documented them nonetheless (Sven: Ping ?) What? Who? Me?! Can't be! (My free time management is really screwed up since I've joined Tumblr -.- *sigh*) What is tumblr and how can I shut it down ? :) It's a social networking site. A look at Wikipedia will help you further ;) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
2015-07-23 8:04 GMT+02:00 Sven Barth pascaldra...@googlemail.com: Am 22.07.2015 23:13 schrieb Maciej Izak hnb.c...@gmail.com: Sorry Sven but I do agree with inline variable declarations. You don't have exclusive rights to dictate what is main point of Pascal (there is also Oxygene, SmartPascal). This is your opinion and this is not ultimate truth. There is also community with experienced users and big part of this community (especially around Delphi and Oxygene, not around FPC core development team :P) needs modern open source Pascal. This is not merely my opinion. The same on my side. There is a great opposition. So again : this is not ultimate truth. Some people love Oxygene, and you can't tell that the Oxygene is not the Pascal. Any new construction will be non pascalish at first glance. No, that depends heavily on the specific construction. Mostly whether it was obviously just ripped from other languages like C# without giving a second thought about the way how things should be done in Pascal (for example attributes or Delphi's generics) or not (for example tuples in Oxygene). IMO Delphi/Oxygene generics are better for real life development. FPC specialize keyword is nightmare and not intuitive construction. Generics should be short in usage. They exist for clear and reusable constructions. I need to cite you: Prefixed modifiers are the /worst/ you can do for Pascal.. By introducing specialize keyword, you deny yourself. So when some crap construction is introduced by FPC team, all is ok, but any proposed solution that is clear/clever, it becomes /non pascalish/, /not main point of Pascal/ and /worst/ thing ever. Ripping smart and productive constructions is good thing. They don't need to be pascalish as hell. best regards Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Wed, 22 Jul 2015, Maciej Izak wrote: 2015-07-22 19:47 GMT+02:00 Sven Barth pascaldra...@googlemail.com: While I agree that type inference /might/ be useful I don't agree with inline variable declarations. One of the main points of Pascal is declare before use. While this is somewhat violated with Delphi compatible generics there one could at least argue that the specialized type is implicitly declared by the generic declaration... Regards, Sven Sorry Sven but I do agree with inline variable declarations. You don't have exclusive rights to dictate what is main point of Pascal (there is also Oxygene, SmartPascal). This is your opinion and this is not ultimate truth. Oxygene is no longer pascal. It's just C# with pascal keywords. a pityful copy. If you want the features of C#, you should use C#, full stop. Regarding inline declarations: Pascal is about bringing clear structure in your code. Plan first, code then. From this point of view there is no need for inline variable declarations. Also, the location of variables is entirely irrelevant with an IDE like Lazarus. Press ctrl-c on a variable and Lazarus inserts it in the correct location, *as required by the language*. It is exactly because the Pascal language is so structured that Lazarus *can* do it. So: People who think they *need* inline variable declarations need in the first place to use another language than pascal or use a better IDE. Given that other languages have inline variable declarations since more than 30 years, the statement that having inline variable declarations makes a language more modern is pure nonsense. It is just a wish of people who think that 'anything goes', it has nothing to do with being more productive or being modern. The 'anything goes' dictum may be nice in modern arts (also often a load of male cow droppings) but has IMO no place in computer programming, where structure is central. Why do you think Google, MS and some others are trying to add structure to a language like Javascript ? exactly so they can do things in a JS IDE like Lazarus already does. As JS is now, they simply cannot, because the language has no structure. But then, all that is just my truth. Yours may be entirely different. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Thu, 23 Jul 2015, Maciej Izak wrote: 2015-07-23 8:04 GMT+02:00 Sven Barth pascaldra...@googlemail.com: Am 22.07.2015 23:13 schrieb Maciej Izak hnb.c...@gmail.com: Sorry Sven but I do agree with inline variable declarations. You don't have exclusive rights to dictate what is main point of Pascal (there is also Oxygene, SmartPascal). This is your opinion and this is not ultimate truth. There is also community with experienced users and big part of this community (especially around Delphi and Oxygene, not around FPC core development team :P) needs modern open source Pascal. This is not merely my opinion. The same on my side. There is a great opposition. So again : this is not ultimate truth. Some people love Oxygene, and you can't tell that the Oxygene is not the Pascal. Any new construction will be non pascalish at first glance. No, that depends heavily on the specific construction. Mostly whether it was obviously just ripped from other languages like C# without giving a second thought about the way how things should be done in Pascal (for example attributes or Delphi's generics) or not (for example tuples in Oxygene). IMO Delphi/Oxygene generics are better for real life development. FPC specialize keyword is nightmare and not intuitive construction. Generics should be short in usage. They exist for clear and reusable constructions. I need to cite you: Prefixed modifiers are the /worst/ you can do for Pascal.. By introducing specialize keyword, you deny yourself. So when some crap construction is introduced by FPC team, all is ok, but any proposed solution that is clear/clever, it becomes /non pascalish/, /not main point of Pascal/ and /worst/ thing ever. Ripping smart and productive constructions is good thing. They don't need to be pascalish as hell. Yes, they do. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
2015-07-23 9:21 GMT+02:00 Michael Van Canneyt mich...@freepascal.org: But then, all that is just my truth. Yours may be entirely different. That is why we have $MODESWITCH and $MODE :). We can all be happy. Please do not destroy the enthusiasm of others. Best regards, Maciej Izak (hnb.c...@gmail.com) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
2015-07-23 9:22 GMT+02:00 Michael Van Canneyt mich...@freepascal.org: Yes, they do. Michael. Not completely :) best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
2015-07-23 9:21 GMT+02:00 Michael Van Canneyt mich...@freepascal.org: Oxygene is no longer pascal. It's just C# with pascal keywords. a pityful copy. If you want the features of C#, you should use C#, full stop. C# is in some way new Pascal so there is nothing wrong with porting back some features from C# to Pascal ^^. I can't use C#. I want to adopt new FPC dialect for that purpose (Oxygene flavored) :). Damn, probably you must hate me. ;) Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Thu, 23 Jul 2015, Maciej Izak wrote: 2015-07-23 9:21 GMT+02:00 Michael Van Canneyt mich...@freepascal.org: Oxygene is no longer pascal. It's just C# with pascal keywords. a pityful copy. If you want the features of C#, you should use C#, full stop. C# is in some way new Pascal so there is nothing wrong with porting back some features from C# to Pascal ^^. I can't use C#. I want to adopt new FPC dialect for that purpose (Oxygene flavored) :). Damn, probably you must hate me. ;) ? Not at all. I simply don't understand why people want to introduce concepts of other languages. Just use the other language, spare yourself the agony. What confuses me even more: C has been around since as long as pascal. It does not seem plagued by this need to be modern. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Thu, 23 Jul 2015, Maciej Izak wrote: 2015-07-23 9:21 GMT+02:00 Michael Van Canneyt mich...@freepascal.org: But then, all that is just my truth. Yours may be entirely different. That is why we have $MODESWITCH and $MODE :). We can all be happy. Please do not destroy the enthusiasm of others. I don't mean to, but my bullshit detector is going in the red these days. For example, the term 'modern' is bullshit and has no place in a technical environment. That's for fashion, where it can change every 6 months. There have been NO fundamental changes in IT in the last 20 years (probably longer). It has *not* become more modern. It is, however, increasingly hype sensitive - unfortunately. Terms like 'modern' only add to the hype. If you want to increase productivity, and think this must be done by changing the language, you are very IMHO very much mistaken, and as a consequence you will have to present stronger arguments to introduce changes. I don't mind changes to the language, but please use correct and compelling arguments. This is not perl. Perl also incorporated a lot of elements from all kinds of tools, it became utterly unreadable and is in free fall ever since. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On 07/22/2015 11:21 PM, Frederic Da Vitoria wrote: Declare before use has at least one technical advantage: it allows to make much faster compliers. Declare before use allows to compile in one pass, while compilers for languages like C need at least 2 passes. ??? ANSI C is a Declare before use language, too. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Thu, 23 Jul 2015, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: ? Not at all. I simply don't understand why people want to introduce concepts of other languages. Just use the other language, spare yourself the agony. Just look at the forum. What is talked there? Languagewise only more Delphi compatibility, unless it is from the people who are actually adding syntax. Overall? Things like fpspreadsheet get more responsed than any language feature combined. Which fully supports my point that we need more libraries, and not language features. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
2015-07-23 11:45 GMT+02:00 Michael Schnell mschn...@lumino.de: On 07/22/2015 11:21 PM, Frederic Da Vitoria wrote: Declare before use has at least one technical advantage: it allows to make much faster compliers. Declare before use allows to compile in one pass, while compilers for languages like C need at least 2 passes. ??? ANSI C is a Declare before use language, too. Ah yes, I was referring to old C syntax. I so much hated it that I never looked back into it since. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
2015-07-23 10:56 GMT+02:00 Michael Van Canneyt mich...@freepascal.org: But I do happen to think many of your arguments are pure bullshit and hype, and of no value whatsoever. I just point that out. I would much prefer that you give REAL technological arguments for your changes. The most convenient technological argument is compatibility with Oxygene. The rest is in many cases a matter of taste. We can endlessly debate what is more readable :) -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Thu, 23 Jul 2015, Maciej Izak wrote: 2015-07-23 10:56 GMT+02:00 Michael Van Canneyt mich...@freepascal.org: But I do happen to think many of your arguments are pure bullshit and hype, and of no value whatsoever. I just point that out. I would much prefer that you give REAL technological arguments for your changes. The most convenient technological argument is compatibility with Oxygene. Well, that's a political argument, I think: we can choose to be not compatible with Oxygene :) (whether or not this would constitute suicide or not, is up for debate) The rest is in many cases a matter of taste. We can endlessly debate what is more readable :) Good. Now you're talking sense :) I look forward to your contributions! Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
Am 23.07.2015 09:21 schrieb Maciej Izak hnb.c...@gmail.com: Some people love Oxygene, and you can't tell that the Oxygene is not the Pascal. Any new construction will be non pascalish at first glance. No, that depends heavily on the specific construction. Mostly whether it was obviously just ripped from other languages like C# without giving a second thought about the way how things should be done in Pascal (for example attributes or Delphi's generics) or not (for example tuples in Oxygene). IMO Delphi/Oxygene generics are better for real life development. FPC specialize keyword is nightmare and not intuitive construction. Generics should be short in usage. They exist for clear and reusable constructions. I need to cite you: Prefixed modifiers are the /worst/ you can do for Pascal.. By introducing specialize keyword, you deny yourself. I should have written this in the other thread where you mentioned this, but I forgot, so: I agree that specialize falls into the same prefixed modifiers are the worst category. The cleanest way for specializations would be something like TMyGeneric with (Longint, String) or so, this way there would be no potential disambiguity. Nevertheless specialize had been introduced before my time, so I'm merely working with what already /is/ part of the Free Pascal dialect (generics were first introduced in 2.2 and I started working on the compiler with 2.6). That said: I /am/ working on Delphi compatible generics (in fact 3.0 is a big improvement compared to 2.6 in that regard, but it's still quite a way to go) and thus you /will/ be able to work with them in mode Delphi. So just use that mode and be happy. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
Am 23.07.2015 10:35 schrieb Maciej Izak hnb.c...@gmail.com: 2015-07-23 10:12 GMT+02:00 Michael Van Canneyt mich...@freepascal.org: I simply don't understand why people want to introduce concepts of other languages. Just use the other language, spare yourself the agony. What confuses me even more: C has been around since as long as pascal. It does not seem plagued by this need to be modern. Michael. If you want the features of pure pascal, you should use $MODE OBJFPC or TP or FPC, full stop. You can't stop me and others from introducing Oxygene flavored mode.Or if inside FPC team is will to block changes related to Oxygene flavored syntax, let me know and I will try to create fork of FPC compiler. It will depend on the changes. For example your proposed strong and weak changes would he rather mediate (I'm not talking about the syntax now, but other changes in the compiler and RTL to implement it), so that is more likely to be accepted then let's say inline variable declarations which might lead to quite massive changes in the compiler. [Note: I'm not saying that those /will/ lead to massive changes, I'm just cautioning you that massive changes will be looked at more sceptically than small ones] Sidenote/warning should you decide to work on the compiler now that you have a branch directory: adhere to the coding style used in the compiler even if you don't like it (I don't either ;) ), because that will definitely be a reason to refuse your code (you wouldn't be the first). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
In our previous episode, Michael Van Canneyt said: ? Not at all. I simply don't understand why people want to introduce concepts of other languages. Just use the other language, spare yourself the agony. Just look at the forum. What is talked there? Languagewise only more Delphi compatibility, unless it is from the people who are actually adding syntax. Overall? Things like fpspreadsheet get more responsed than any language feature combined. What confuses me even more: C has been around since as long as pascal. It does not seem plagued by this need to be modern. That's because basic syntax is inherited by all other languages. It is so pervasive that most accept it as a given without thinking, and want to change everything to it. What worries me most is that language debate is again driven by shortness of notation and other very local typing optimizations (like the var block). Typing was never the limiting factor in programming, and carving up the language for typing's sake will not have a noticable effect on any production use of the (FP-)pascal language. If, and only if you want to do language extensions, it should be about making new aspects doable, not reducing typing and increasing superficial language syntax. (moreover can you borrow C syntax without accepting C's everything is an int expression mantra? Can you randomly borrow from C# (and its slightly Wirthianized cousin Oxygene) without changing into a GCed language and a Java/C# typesystem?) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On 07/23/2015 09:21 AM, Michael Van Canneyt wrote: If you want the features of C#, you should use C#, full stop. True for syntax variant features. But *some* syntax candy for common multi thread usage cases (e.g. a parallel loop) nowadays is a necessity. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
Just a couple of reactions: Declare before use has at least one technical advantage: it allows to make much faster compliers. Declare before use allows to compile in one pass, while compilers for languages like C need at least 2 passes. Not really. TCC does a single pass with no intermediate representation. It leaves a gap in the procedure prologue for the code that moves the stack pointer and fills it in when it gets to the end of the function and knows how much space is required for the local variables and temporaries. There have been NO fundamental changes in IT in the last 20 years (probably longer). One could argue that multi-core and concern about security are fairly fundamental changes. Both have lead to people trying to do sophisticated static analysis of code whose use of pointers makes that analysis, in general, rather difficult. Edmund ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Thu, 23 Jul 2015, Maciej Izak wrote: If you want the features of pure pascal, you should use $MODE OBJFPC or TP or FPC, full stop. You can't stop me and others from introducing Oxygene flavored mode.Or if inside FPC team is will to block changes related to Oxygene flavored syntax, let me know and I will try to create fork of FPC compiler. I think you are mistaken about my motivation: I have no intention of stopping anyone. Go ahead. On the contrary: in the end, you do introduce changes, I will even document them. I don't believe generics are the nec-plus-ultra of pascal (or any language). I documented them nonetheless (Sven: Ping ?) But I do happen to think many of your arguments are pure bullshit and hype, and of no value whatsoever. I just point that out. I would much prefer that you give REAL technological arguments for your changes. I also explicitly said that these statements are my personal opinion. So, we can at least agree to disagree, no ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
2015-07-23 10:12 GMT+02:00 Michael Van Canneyt mich...@freepascal.org: I simply don't understand why people want to introduce concepts of other languages. Just use the other language, spare yourself the agony. What confuses me even more: C has been around since as long as pascal. It does not seem plagued by this need to be modern. Michael. If you want the features of pure pascal, you should use $MODE OBJFPC or TP or FPC, full stop. You can't stop me and others from introducing Oxygene flavored mode.Or if inside FPC team is will to block changes related to Oxygene flavored syntax, let me know and I will try to create fork of FPC compiler. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Thu, 23 Jul 2015, Michael Schnell wrote: On 07/23/2015 09:21 AM, Michael Van Canneyt wrote: If you want the features of C#, you should use C#, full stop. True for syntax variant features. But *some* syntax candy for common multi thread usage cases (e.g. a parallel loop) nowadays is a necessity. Support for a parallel loop is more than syntax candy, it is a fundamental language change and hence falls under 'compelling arguments'. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On 07/23/2015 10:34 AM, Michael Van Canneyt wrote: Support for a parallel loop is more than syntax candy, it is a fundamental language change and hence falls under 'compelling arguments'. I suppose that happily such syntax supposedly will be a pure extension and not interfere with the traditional Pascal syntax in any $MODE. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Thu, 23 Jul 2015, Edmund Grimley Evans wrote: Just a couple of reactions: Declare before use has at least one technical advantage: it allows to make much faster compliers. Declare before use allows to compile in one pass, while compilers for languages like C need at least 2 passes. Not really. TCC does a single pass with no intermediate representation. It leaves a gap in the procedure prologue for the code that moves the stack pointer and fills it in when it gets to the end of the function and knows how much space is required for the local variables and temporaries. There have been NO fundamental changes in IT in the last 20 years (probably longer). One could argue that multi-core and concern about security are fairly fundamental changes. No. It is just more of the same. I think that, currently, Quantum computing has the potential of introducing a real change. The advent of SSD may have some effect in that in theory you don't need file operations any more, since everyting is in essence RAM. But that's it. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
In our previous episode, Michael Van Canneyt said: compatibility, unless it is from the people who are actually adding syntax. Overall? Things like fpspreadsheet get more responsed than any language feature combined. Which fully supports my point that we need more libraries, and not language features. That, and IF there are language support enhancements, they need to be as minimal as possible and in support of some major library concept. Not just syntax for syntax' sake talked up because of some perceived typing advantages. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
In our previous episode, Maciej Izak said: technological arguments for your changes. The most convenient technological argument is compatibility with Oxygene. If oxygene is what you want, I recommend you start at the basis, and not superficial details. Maybe there is some overlap with the JVM work you can build on. But IMHO it is nuts for the native modes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On 22/07/15 19:24, Paul van Helden wrote: What is wrong with a language evolving to allow (in addition to the above)?: if X is not TSomeClass then .. if 5 not in [1,2,3] then .. I'm not a compiler programmer, but it almost seems like laziness that the second case is not possible already? If the not operator is overloaded in TSomeClass, not TSomeClass can be a valid expression in itself. not in could never be anything else, but consistency is also very important. Additionally, keeping the compiler fast and maintainable (and able to produce sensible error messages when syntax errors are found) conflicts with arbitrary word orders. Calling that laziness is a bit blunt. IMO the design philosophy should be: if it is more readable it should be allowed. Allowing multiple ways to say the same thing generally does not increase readability, even if in isolation it can look fine. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
Am 22.07.2015 19:25 schrieb Paul van Helden p...@planetgis.co.za: On Mon, Jul 20, 2015 at 8:39 PM, Marcos Douglas m...@delfire.net wrote: On Mon, Jul 20, 2015 at 3:14 PM, Ralf Quint freedos...@gmail.com wrote: [...] And quite frankly, what I have seen in object oriented code in recent years, I would rather take as a negative example of evolution, of ways/things not to go/do... That is true. Many programmers think that coding using object orientation only because they use an object-oriented language. They also think that using a more cool syntax makes your code more professional. But some evolutions in a language could be a good thing, as Sven have said. Yes, so for example we currently have: if not (X is TSomeClass) then .. if not (5 in [1,2,3]) then .. What is wrong with a language evolving to allow (in addition to the above)?: if X is not TSomeClass then .. if 5 not in [1,2,3] then .. I'm not a compiler programmer, but it almost seems like laziness that the second case is not possible already? Maybe something is really hard with multi-word operators? The compiler is geared towards single word operators (combined with their precedence). Convenience should be added to this. Take for example type inference. If the compiler can easily figure out the type of a result, why should I have to declare a variable first with the appropriate type? Of course that means to allow var declarations inside the code block. Something I've always wanted to see in Pascal since my brief stint with C++ in the early 90s. The standard argument against is probably that is unPascallish or that it is moving away from strong typing. I disagree: if the compiler can figure things out before runtime you still have strong typing. So, for example, I would like to declare something like this anywhere inside a begin..end block: var A := SomeClassInstance.SomeFunction; While I agree that type inference /might/ be useful I don't agree with inline variable declarations. One of the main points of Pascal is declare before use. While this is somewhat violated with Delphi compatible generics there one could at least argue that the specialized type is implicitly declared by the generic declaration... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Mon, Jul 20, 2015 at 8:39 PM, Marcos Douglas m...@delfire.net wrote: On Mon, Jul 20, 2015 at 3:14 PM, Ralf Quint freedos...@gmail.com wrote: [...] And quite frankly, what I have seen in object oriented code in recent years, I would rather take as a negative example of evolution, of ways/things not to go/do... That is true. Many programmers think that coding using object orientation only because they use an object-oriented language. They also think that using a more cool syntax makes your code more professional. But some evolutions in a language could be a good thing, as Sven have said. Yes, so for example we currently have: if not (X is TSomeClass) then .. if not (5 in [1,2,3]) then .. What is wrong with a language evolving to allow (in addition to the above)?: if X is not TSomeClass then .. if 5 not in [1,2,3] then .. I'm not a compiler programmer, but it almost seems like laziness that the second case is not possible already? Maybe something is really hard with multi-word operators? I like Pascal because it is more readable than Java, C#, Ruby, Haskell, etc. IMO the design philosophy should be: if it is more readable it should be allowed. Convenience should be added to this. Take for example type inference. If the compiler can easily figure out the type of a result, why should I have to declare a variable first with the appropriate type? Of course that means to allow var declarations inside the code block. Something I've always wanted to see in Pascal since my brief stint with C++ in the early 90s. The standard argument against is probably that is unPascallish or that it is moving away from strong typing. I disagree: if the compiler can figure things out before runtime you still have strong typing. So, for example, I would like to declare something like this anywhere inside a begin..end block: var A := SomeClassInstance.SomeFunction; It *looks* like JavaScript's (etc) weak typing but it is not. The compiler will catch any mischief that may follow with the variable A. We've eliminated a line of code that needs to be changed if the type of the function result changes. And to me it still looks very Pascallish.. I can carry on.. tuples can save lots of lines of code while at the same time making it more readable. How as that not cool? :-) (or functional for that matter!) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
In our previous episode, Paul van Helden said: Yes, so for example we currently have: if not (X is TSomeClass) then .. if not (5 in [1,2,3]) then .. What is wrong with a language evolving to allow (in addition to the above)?: Evolution in languages is like the evolution in organisms. Those who evolve wrong or expend energy on features that are not contributing to survival eventually perish. So basically it all boils down to benefit/cost tradeoff, with cost both implementation AND maintenance. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On 7/22/2015 1:13 PM, Paul van Helden wrote: Ralf, I guess I'm talking about losing the third hand and join all the other languages with two hands (so, minus the var block before begin :-) ). This is not about being lazy, but about being less verbose. Or in other words shorter text which is more expressive and more readable. That's sounds like the guy from Symbolics 30 years ago, when he tried to convince me that Lisp is the most expressive and readable programming language... ;-) Ralf --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Wed, Jul 22, 2015 at 8:15 PM, Marco van de Voort mar...@stack.nl wrote: In our previous episode, Paul van Helden said: Yes, so for example we currently have: if not (X is TSomeClass) then .. if not (5 in [1,2,3]) then .. What is wrong with a language evolving to allow (in addition to the above)?: Evolution in languages is like the evolution in organisms. Those who evolve wrong or expend energy on features that are not contributing to survival eventually perish. So basically it all boils down to benefit/cost tradeoff, with cost both implementation AND maintenance. Understood. I'm not trying to make completely practical points here. I'm just trying to add to the conversation about improving the language which I love. And I'm not even suggesting anything new: these are concepts already embraced by main-stream languages. For new projects Object Pascal seems to be going the way of the dinosaur and I would like to see my favourite compiler (FPC) compete with more than Delphi. Oxygene, for example. If FPC+Lazarus is simply the anti-Delphi (to clarify: the open source alternative to / clone of Delphi), then I guess I am barking up the wrong tree. It just seems that this group is the only hope for an open source modern Pascal right now... :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On 22.07.2015 20:20, Paul van Helden wrote: On Wed, Jul 22, 2015 at 7:47 PM, Sven Barth pascaldra...@googlemail.com mailto:pascaldra...@googlemail.com wrote: I'm not a compiler programmer, but it almost seems like laziness that the second case is not possible already? Maybe something is really hard with multi-word operators? The compiler is geared towards single word operators (combined with their precedence). Is it technically infeasible to expand this to two-word operators? SQL did it.. Not without reworking quite some parts of the parser. Convenience should be added to this. Take for example type inference. If the compiler can easily figure out the type of a result, why should I have to declare a variable first with the appropriate type? Of course that means to allow var declarations inside the code block. Something I've always wanted to see in Pascal since my brief stint with C++ in the early 90s. The standard argument against is probably that is unPascallish or that it is moving away from strong typing. I disagree: if the compiler can figure things out before runtime you still have strong typing. So, for example, I would like to declare something like this anywhere inside a begin..end block: var A := SomeClassInstance.SomeFunction; While I agree that type inference /might/ be useful I don't agree with inline variable declarations. One of the main points of Pascal is declare before use. While this is somewhat violated with Delphi compatible generics there one could at least argue that the specialized type is implicitly declared by the generic declaration... I have never managed to understand why declare before use is so important to Pascal. I get the bit about strong typing and doing everything possible to eliminate errors at compile time, but I still don't get why. If this is central to what makes something Pascal, I would love to be pointed to a good explanation. I'm not trying to be a pain here. I've been programming in Pascal, full time, for most of my life. It has always puzzled me why everything has to be declared first. Because with that you have specific locations where variables are declared. You can see with one look (yes, I'm simplifying here) what variables are used in the function even if you don't have a fancy IDE that highlights it. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On 7/22/2015 10:47 AM, Sven Barth wrote: var A := SomeClassInstance.SomeFunction; While I agree that type inference /might/ be useful I don't agree with inline variable declarations. One of the main points of Pascal is declare before use. +100 Things like this is just because people are trying to be lazy, not because this does improve code (human readable or otherwise). Someone who is trying to use a construct like the one mentioned above is nothing but lazy, is not properly designing his/her software. And that is against what Pascal should stand for. Humans miss a lot of times a third hand, but this isn't likely to happen that we grow one anytime soon. So get used to properly using what you have... Ralf --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Wed, Jul 22, 2015 at 9:45 PM, Ralf Quint freedos...@gmail.com wrote: On 7/22/2015 10:47 AM, Sven Barth wrote: var A := SomeClassInstance.SomeFunction; While I agree that type inference /might/ be useful I don't agree with inline variable declarations. One of the main points of Pascal is declare before use. +100 Things like this is just because people are trying to be lazy, not because this does improve code (human readable or otherwise). Someone who is trying to use a construct like the one mentioned above is nothing but lazy, is not properly designing his/her software. And that is against what Pascal should stand for. Humans miss a lot of times a third hand, but this isn't likely to happen that we grow one anytime soon. So get used to properly using what you have... Ralf Ralf, I guess I'm talking about losing the third hand and join all the other languages with two hands (so, minus the var block before begin :-) ). This is not about being lazy, but about being less verbose. Or in other words shorter text which is more expressive and more readable. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Wed, Jul 22, 2015 at 7:47 PM, Sven Barth pascaldra...@googlemail.com wrote: I'm not a compiler programmer, but it almost seems like laziness that the second case is not possible already? Maybe something is really hard with multi-word operators? The compiler is geared towards single word operators (combined with their precedence). Is it technically infeasible to expand this to two-word operators? SQL did it.. Convenience should be added to this. Take for example type inference. If the compiler can easily figure out the type of a result, why should I have to declare a variable first with the appropriate type? Of course that means to allow var declarations inside the code block. Something I've always wanted to see in Pascal since my brief stint with C++ in the early 90s. The standard argument against is probably that is unPascallish or that it is moving away from strong typing. I disagree: if the compiler can figure things out before runtime you still have strong typing. So, for example, I would like to declare something like this anywhere inside a begin..end block: var A := SomeClassInstance.SomeFunction; While I agree that type inference /might/ be useful I don't agree with inline variable declarations. One of the main points of Pascal is declare before use. While this is somewhat violated with Delphi compatible generics there one could at least argue that the specialized type is implicitly declared by the generic declaration... I have never managed to understand why declare before use is so important to Pascal. I get the bit about strong typing and doing everything possible to eliminate errors at compile time, but I still don't get why. If this is central to what makes something Pascal, I would love to be pointed to a good explanation. I'm not trying to be a pain here. I've been programming in Pascal, full time, for most of my life. It has always puzzled me why everything has to be declared first. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On 22/07/15 19:20, Paul van Helden wrote: I have never managed to understand why declare before use is so important to Pascal. I get the bit about strong typing and doing everything possible to eliminate errors at compile time, but I still don't get why. If this is central to what makes something Pascal, I would love to be pointed to a good explanation. I'm not trying to be a pain here. I've been programming in Pascal, full time, for most of my life. It has always puzzled me why everything has to be declared first. Consider the following code: procedure Test; var i : integer; begin for J := 1 to 25 do writeln; end; With Declare before use, this is plainly incorrect. J has not been declared; You can't type; You are an idiot! In your world, it may be an error (see above), it may be a warning; I has been declared and not used. You may have warnings switched off and never even see it! I like my compilers to find as many errors in my code as possible ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
2015-07-22 20:20 GMT+02:00 Paul van Helden p...@planetgis.co.za: I have never managed to understand why declare before use is so important to Pascal. I get the bit about strong typing and doing everything possible to eliminate errors at compile time, but I still don't get why. If this is central to what makes something Pascal, I would love to be pointed to a good explanation. I'm not trying to be a pain here. I've been programming in Pascal, full time, for most of my life. It has always puzzled me why everything has to be declared first. Declare before use has at least one technical advantage: it allows to make much faster compliers. Declare before use allows to compile in one pass, while compilers for languages like C need at least 2 passes. But declare before use is also part of the Pascal philosophy. Pascal tries to prevent you from programming by just throwing in some straws, some nails and a bit of wire when needed. Pascal was designed so that you have to plan first and code only when your plans are ready. If you want to do quick and dirty programming (I agree doing complete plans before would sometimes be overkill), then use a scripting language. Of course, other 3rd gen languages also allow you to do completely structured programming, but Pascal was created to push users to do it. There is a joke about Pascal that Pascal is so coercive about good programming that you could program in Pascal for years and still not learn how to program correctly. Hmm, maybe this is not entirely a joke :-) -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
2015-07-22 23:16 GMT+02:00 Marco van de Voort mar...@stack.nl: By that reasoning I can't tell that C++ isn't the new Pascal either. Everything is relative. Languages derived from each other and that's ok. best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
In our previous episode, Maciej Izak said: Sorry Sven but I do agree with inline variable declarations. You don't have exclusive rights to dictate what is main point of Pascal (there is also Oxygene, SmartPascal). This is your opinion and this is not ultimate truth. There is also community with experienced users and big part of this community (especially around Delphi and Oxygene, not around FPC core development team :P) needs modern open source Pascal. Some people love Oxygene, and you can't tell that the Oxygene is not the Pascal. Any new construction will be non pascalish at first glance. By that reasoning I can't tell that C++ isn't the new Pascal either. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
2015-07-22 19:47 GMT+02:00 Sven Barth pascaldra...@googlemail.com: While I agree that type inference /might/ be useful I don't agree with inline variable declarations. One of the main points of Pascal is declare before use. While this is somewhat violated with Delphi compatible generics there one could at least argue that the specialized type is implicitly declared by the generic declaration... Regards, Sven Sorry Sven but I do agree with inline variable declarations. You don't have exclusive rights to dictate what is main point of Pascal (there is also Oxygene, SmartPascal). This is your opinion and this is not ultimate truth. There is also community with experienced users and big part of this community (especially around Delphi and Oxygene, not around FPC core development team :P) needs modern open source Pascal. Some people love Oxygene, and you can't tell that the Oxygene is not the Pascal. Any new construction will be non pascalish at first glance. Best Regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
In our previous episode, Sven Barth said: The way we write software evolves however. Things that were thought as state of the art 25 years ago aren't necessarily nowadays (for example procedural programming that has been mostly superseded by object oriented programming). And in this regards programming languages are like natural languages: they evolve, they change. If a language doesn't evolve anymore it can be considered dead (e.g. Latin, Ancient Greek). So I personally support the addition of new features to FPC as long as they don't interfere with backwards compatibility and fit into the language as a whole. The question though if a few haphazardly copied features make a 20+ year old project suddenly state of the art. Some of the old stuff goes deep. Translation modern comic books to Latin didn't really have a lasting affect on Latin uptake. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
Am 19.07.2015 23:43 schrieb Ralf Quint freedos...@gmail.com: Now today, I do not necessarily agree with the direction Embarcadero heading these days with Delphi and most importantly (for me), I do not agree with all those attempts to add features of other languages to Free Pascal. I appreciate the efforts of the folks involved in Free Pascal for a long time, as this provides me with the opportunity to keep working in the programming language/environment that for me makes the most sense and that I am used to for 38 years. And I honestly loath to see that people argue that there should be new language constructs and such, just because it is what more popular programming languages provide. I am not in to participate in a popularity contest, I am trying to get work done... The way we write software evolves however. Things that were thought as state of the art 25 years ago aren't necessarily nowadays (for example procedural programming that has been mostly superseded by object oriented programming). And in this regards programming languages are like natural languages: they evolve, they change. If a language doesn't evolve anymore it can be considered dead (e.g. Latin, Ancient Greek). So I personally support the addition of new features to FPC as long as they don't interfere with backwards compatibility and fit into the language as a whole. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On 7/19/2015 11:03 PM, Sven Barth wrote: The way we write software evolves however. Things that were thought as state of the art 25 years ago aren't necessarily nowadays (for example procedural programming that has been mostly superseded by object oriented programming). And in this regards programming languages are like natural languages: they evolve, they change. If a language doesn't evolve anymore it can be considered dead (e.g. Latin, Ancient Greek). But evolving doesn't mean you have to turn (Free)Pascal in another incarnation of Python, Ruby, Haskell or whatever. And a lot of basic programming paradigms that existed 25 years ago are just as valid today. There is nothing wrong with procedural programming, just as there is nothing inherently wrong with object oriented programming. You can abuse and misuse both approaches. And quite frankly, what I have seen in object oriented code in recent years, I would rather take as a negative example of evolution, of ways/things not to go/do... Ralf --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Mon, Jul 20, 2015 at 3:14 PM, Ralf Quint freedos...@gmail.com wrote: [...] And quite frankly, what I have seen in object oriented code in recent years, I would rather take as a negative example of evolution, of ways/things not to go/do... That is true. Many programmers think that coding using object orientation only because they use an object-oriented language. They also think that using a more cool syntax makes your code more professional. But some evolutions in a language could be a good thing, as Sven have said. Regards, Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Mon, Jul 20, 2015 at 3:03 AM, Sven Barth pascaldra...@googlemail.com wrote: The way we write software evolves however. Things that were thought as state of the art 25 years ago aren't necessarily nowadays (for example procedural programming that has been mostly superseded by object oriented programming). And in this regards programming languages are like natural languages: they evolve, they change. If a language doesn't evolve anymore it can be considered dead (e.g. Latin, Ancient Greek). So I personally support the addition of new features to FPC as long as they don't interfere with backwards compatibility and fit into the language as a whole. +1 Regards, Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Sun, 19 Jul 2015, Den wrote: Hi all, There's been recent talk about adding a new dialect and such, and I just wanna weigh in that I don't think it's a very good call to split Free Pascal even more.. I believe Free Pascal had such potential.. And the reason I mention 'had' is the fact that makes Free Pascal 'strong' also makes it it's biggest weakness and downfall; The fact that there is no direction and lead, and everyone can add whatever they want. The difference between Free Pascal and successful big languages are *leadership*, *roadmap*, *community*, *support*. Now I know the usuals will start immediately thinking 'yes but it's all volunteer, we don't have the man power' .. Why is many other languages believed to be more popular? Why do you say there is no support ? There is. Mailing lists, forums, and even a company that offers paid support. *Standards**.* If we had a group of people that designed standards (/a group document??/), people like me can see the new standard and say 'oh, nice I like that feature, I'm gonna implement it'. Let's say someone else makes a completely LLVM compiler based on that standard? So what if it's not one program, at least Pascal would 'survive'. Just like ECMAScript, C++, PHP, most languages now have a 'standards' document behind it. That's their *roadmap*. Their *leadership*. Design it and the *community* will show *support*. I know I would actually feel like working towards it, because then I know when they are approved I'm not wasting my time creating features and such, just to have them rejected and never implemented. ;) I would personally love to add to such standards, and we can add some of the collective wisdom of ours. :) (/I have 22+ years of experience with Pascal, and I'm sure Florian, Sven, Marco, and Jonas all have similar if not much more; and would be excellent at adding to the standard/) What stops you from starting such an effort ? You can start e.g. by adding the tuples idea which was discussed on the mailing list several years ago. I have 28 years of Pascal experience which is completely at your disposal... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Sun, 19 Jul 2015, Jonas Maebe wrote: Den wrote: Just like ECMAScript, C++, PHP, most languages now have a 'standards' document behind it. That's their *roadmap*. Their *leadership*. Design it and the *community* will show *support*. ISO Pascal and ISO Extended Pascal were like that in the early 90s: 1) there was an official ISO standard and standards committee for it 2) there were a number commercial compilers supporting it such as HP Pascal and IBM's compiler for its System/370 3) later on (in 1996) a GCC-based implementation arrived for it (the equivalent of the LLVM of the moment) And still almost no one uses ISO/Extended Pascal anymore. Why? Possibly because the de facto Pascal standards had already become Think Pascal on the Mac and Turbo Pascal on the PC by then, and none of those programmers wanted to rewrite all of their code (although Think Pascal was a bit closer to ISO Pascal). Or maybe because in general, many people just preferred those language dialects for one reason or another. In any case, introducing one new standard to rule them all seldom (if ever) works It doesn't even work for magical rings. Although it took 3000 years to find that out. Nevertheless, I must agree a roadmap for FPC with some detailed proposals would be nice. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Pascal Standard, and what we can do.
Hi all, There's been recent talk about adding a new dialect and such, and I just wanna weigh in that I don't think it's a very good call to split Free Pascal even more.. I believe Free Pascal had such potential.. And the reason I mention 'had' is the fact that makes Free Pascal 'strong' also makes it it's biggest weakness and downfall; The fact that there is no direction and lead, and everyone can add whatever they want. The difference between Free Pascal and successful big languages are *leadership*, *roadmap*, *community*, *support*. Now I know the usuals will start immediately thinking 'yes but it's all volunteer, we don't have the man power' .. Why is many other languages believed to be more popular? *Standards**.* If we had a group of people that designed standards (/a group document??/), people like me can see the new standard and say 'oh, nice I like that feature, I'm gonna implement it'. Let's say someone else makes a completely LLVM compiler based on that standard? So what if it's not one program, at least Pascal would 'survive'. Just like ECMAScript, C++, PHP, most languages now have a 'standards' document behind it. That's their *roadmap*. Their *leadership*. Design it and the *community* will show *support*. I know I would actually feel like working towards it, because then I know when they are approved I'm not wasting my time creating features and such, just to have them rejected and never implemented. ;) I would personally love to add to such standards, and we can add some of the collective wisdom of ours. :) (/I have 22+ years of experience with Pascal, and I'm sure Florian, Sven, Marco, and Jonas all have similar if not much more; and would be excellent at adding to the standard/) - Dennis Fehr ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
Jonas Maebe wrote: Den wrote: Just like ECMAScript, C++, PHP, most languages now have a 'standards' document behind it. That's their *roadmap*. Their *leadership*. Design it and the *community* will show *support*. ISO Pascal and ISO Extended Pascal were like that in the early 90s: 1) there was an official ISO standard and standards committee for it 2) there were a number commercial compilers supporting it such as HP Pascal and IBM's compiler for its System/370 3) later on (in 1996) a GCC-based implementation arrived for it (the equivalent of the LLVM of the moment) And still almost no one uses ISO/Extended Pascal anymore. Why? Possibly because the de facto Pascal standards had already become Think Pascal on the Mac and Turbo Pascal on the PC by then, and none of those programmers wanted to rewrite all of their code (although Think Pascal was a bit closer to ISO Pascal). Or maybe because in general, many people just preferred those language dialects for one reason or another. In any case, introducing one new standard to rule them all seldom (if ever) works (and you can bet someone will be unable to resist to add a link to the related xkcd comic). I was selling and supporting development tools in the late 80s. From memory, there was one compiler (in the PC arena) that prided itself on robust ISO Pascal support and expressed little interest in extending towards any of the de-facto standards: nobody bought it. Their Wp page still claims It is the only compiler in existence that fully implements the ISO 10206 standard for Extended Pascal. I still have occasional problems with an old hand on a private conferencing system I use. He worked for Olivetti in the 80s, and found that he and his colleagues were mandated to write an operating system and support software in unextended ISO Pascal. In retrospect, that is universally recognised as being an inappropriate combination, but almost everybody at the time could see it as well... he still misses no opportunity to denigrate pascal as being grossly incomplete for real work. This one? https://xkcd.com/927/ Standards do not magically make a language more popular. They only work if they follow from a desire of an entire community to design one and to adhere to it. Design it and the community will show support is exactly the opposite of what happens in practice. Which in practice means that we'd need to get all of the major post-Borland compilers pulling in the same direction, starting off with Gnu Pascal, and would need to get Embarcadero committing themselves to long-term language stability. Formal standards only work if they have the support of a major standards body from day one. And informal industry standards normally take the form of openly-published documentation, and we've got that in abundance (but if Den wants to help with the indexing, I'm sure we'd all appreciate it). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On 19/07/15 11:12, Michael Van Canneyt wrote: Nevertheless, I must agree a roadmap for FPC with some detailed proposals would be nice. I've created a page with what I know is under development at http://wiki.freepascal.org/FPC_Roadmap Just arbitrary proposals of what some people think would a be a good idea doesn't seem very useful to me, because in general the problem is not so much lack of ideas as it is lack of time, the ability to implement them and keeping the language and compiler clean and maintainable. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Sun, 19 Jul 2015, Jonas Maebe wrote: On 19/07/15 11:12, Michael Van Canneyt wrote: Nevertheless, I must agree a roadmap for FPC with some detailed proposals would be nice. I've created a page with what I know is under development at http://wiki.freepascal.org/FPC_Roadmap Just arbitrary proposals of what some people think would a be a good idea doesn't seem very useful to me, because in general the problem is not so much lack of ideas as it is lack of time, the ability to implement them and keeping the language and compiler clean and maintainable. Hence the 'with some detailed proposals'. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
Am 19.07.2015 13:18 schrieb Jonas Maebe jonas.ma...@elis.ugent.be: On 19/07/15 11:12, Michael Van Canneyt wrote: Nevertheless, I must agree a roadmap for FPC with some detailed proposals would be nice. I've created a page with what I know is under development at http://wiki.freepascal.org/FPC_Roadmap Just arbitrary proposals of what some people think would a be a good idea doesn't seem very useful to me, because in general the problem is not so much lack of ideas as it is lack of time, the ability to implement them and keeping the language and compiler clean and maintainable. Especially the maintainable is important. The more I work around in the parser the more I have the feeling that sooner or later we'll have to rework it. Analogous to how the backend was reworked for 2.0.0. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
I am quite aware of ISO Pascal.. Though, to be fair it wasn't well known and the tools for adding 'rfc' style proposals must not have been great? I've proposed a few new properties to the CSS documents standard, and you know what? It felt great. They're discussing it now and I can track it. If it succeeds, it will be implemented. It's things like that, having a group effort with the documents and the actual 'technical engineers' work on it. You won't have to worry about big heads and businesses taking over the document, as it will be an open effort, just like FPC is. When someone looks at a roadmap, that's the 'output' people look to and see on what to expect in the future. What we'd be doing is discussing proposals and such to make Free Pascal a standard. Who knows? Maybe Delphi would start trying to implement our standards? Is there any such online software anyone is aware of, that is an easy 'proposal'/'rfc' style interface? Where you can make suggestions, comments and votes on each proposal? If there is enough votes on a particular proposal someone could see the potential and add it without fear of it not being accepted. - Dennis Fehr On 2015-07-19 04:42 PM, Ralf Quint wrote: On 7/19/2015 2:03 AM, Jonas Maebe wrote: Den wrote: Just like ECMAScript, C++, PHP, most languages now have a 'standards' document behind it. That's their *roadmap*. Their *leadership*. Design it and the *community* will show *support*. ISO Pascal and ISO Extended Pascal were like that in the early 90s: 1) there was an official ISO standard and standards committee for it 2) there were a number commercial compilers supporting it such as HP Pascal and IBM's compiler for its System/370 3) later on (in 1996) a GCC-based implementation arrived for it (the equivalent of the LLVM of the moment) And still almost no one uses ISO/Extended Pascal anymore. Why? Possibly because the de facto Pascal standards had already become Think Pascal on the Mac and Turbo Pascal on the PC by then, and none of those programmers wanted to rewrite all of their code (although Think Pascal was a bit closer to ISO Pascal). Or maybe because in general, many people just preferred those language dialects for one reason or another. In any case, introducing one new standard to rule them all seldom (if ever) works (and you can bet someone will be unable to resist to add a link to the related xkcd comic). Standards do not magically make a language more popular. They only work if they follow from a desire of an entire community to design one and to adhere to it. Design it and the community will show support is exactly the opposite of what happens in practice. ISO Pascal was a born a dead horse. Borland, itself taking pieces of USCD Pascal (Units, Strings) became the de-factostandard and that is what the initial goal was when Florian started the compiler way back when. Later, Free Pascal followed what was set by Delphi, making the most sense. Now today, I do not necessarily agree with the direction Embarcadero heading these days with Delphi and most importantly (for me), I do not agree with all those attempts to add features of other languages to Free Pascal. I appreciate the efforts of the folks involved in Free Pascal for a long time, as this provides me with the opportunity to keep working in the programming language/environment that for me makes the most sense and that I am used to for 38 years. And I honestly loath to see that people argue that there should be new language constructs and such, just because it is what more popular programming languages provide. I am not in to participate in a popularity contest, I am trying to get work done... Ralf --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel