Recent

Author Topic: Considerations in the decision of adding a feature to the FPC compiler?  (Read 6047 times)

440bx

  • Hero Member
  • *****
  • Posts: 3944
Hello,

Obviously, if a feature is present in Delphi it will likely, at least, be considered for inclusion in FPC.

OTH, there are features in FPC that are not in Delphi and probably will never be in Delphi - such as +=, *=, etc - and those are the kinds of features I'd like to know how they get to make it into FPC.

Is there some somewhat "formal"/"structured" process that leads to the decision of including/excluding such features ?

Is developing the Pascal language _beyond_ any current implementation something that is of interest to the FPC developers ?

thank you.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Thaddy

  • Hero Member
  • *****
  • Posts: 14204
  • Probably until I exterminate Putin.
Any feature is considered as you know from the developer list.
But some "features" are likely to be not implemented ever.
E.g: inline variables.... :o :D ;) O:-)

And Delphi is not the holy grail: They dropped some features from their last beta's that work in FPC like a charm: e.g (again) they dropped management operators for their releases, which are perfectly OK in FPC...... O:-)
OTOH I miss one single feature that Delphi has and FPC doesn't: Anonymous methods. That's the only one.(mind you, this is is costly regarding performance in Delphi!)
But in Delphi I miss even more important features like free standing operator overloads...... 8-)
« Last Edit: June 11, 2019, 06:59:59 pm by Thaddy »
Specialize a type, not a var.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Obviously, if a feature is present in Delphi it will likely, at least, be considered for inclusion in FPC.

But not necessarily now, and doing certain features *well* often relies on deeper work, and a quick hack solution will often not be accepted.

Quote
OTH, there are features in FPC that are not in Delphi and probably will never be in Delphi - such as +=, *=, etc - and those are the kinds of features I'd like to know how they get to make it into FPC.

Those are 2 decades old, so that is hard to answer, back then people like Peter or Florian simply committed them.

Quote
Is there some somewhat "formal"/"structured" process that leads to the decision of including/excluding such features ?

No. If a committer wants to commit them, there is sometimes discussion on maillists. Unfortunately IMHO it gets accepted way too often with the argument "you don't have to use it if you don't like it".

Quote
Is developing the Pascal language _beyond_ any current implementation something that is of interest to the FPC developers ?

This is a very coloured question, and as such unanswerable.

But IMHO FPC already got way to many redundant micro-syntax extensions (all of which were described by the authors as the axis that the whole world revolves around and as such a matter of life and death). But such features and the interactions with other features and platforms (new or existing) have to be maintained indefinitely, a fact that is often grossly underestimated by people peddling new syntax (which are often "done" if it works for x86 or x64)

FPC has a mission to build a production compiler, and that means all facets of the projects, not just language. For experimenting with language extensions, non compatible faster moving projects or forks are better suited I think.

I already think the rate of new (non compatible) syntax adoption in recent years has been to high.

Thaddy

  • Hero Member
  • *****
  • Posts: 14204
  • Probably until I exterminate Putin.
[I already think the rate of new (non compatible) syntax adoption in recent years has been to high.
I agree.
The features are nice like a kid in the candy box, but they are currently overwhelming.
Only old hands can see through it.
« Last Edit: June 11, 2019, 07:16:07 pm by Thaddy »
Specialize a type, not a var.

440bx

  • Hero Member
  • *****
  • Posts: 3944
@Marco

I share your feeling that FPC includes features that are of "dubious" value.

From what you stated, I get the impression that, there really isn't a structured approach to deciding which features are good candidates to be added to the language.

Is developing the Pascal language _beyond_ any current implementation something that is of interest to the FPC developers ?

This is a very coloured question, and as such unanswerable.
I don't think so (but I don't want to argue about it.) 

IMO, there should be an individual or group of individuals who have a vision of where FPC is going as a flavor of Pascal and not just as a mostly "Delphi compatible" implementation of the language.

It's fairly obvious that, at one time, Florian (and possibly others) had a clear vision of what FPC was supposed to be and where it was going, which was, providing a Turbo Pascal/Delphi compatible implementation of the language.  As Borland/Inprise/Embarcadero fiddled with the language definition in ways that were "questionable", that goal became, justifiably, less desirable.

At this time, I am under the impression that Delphi compatibility, while still important, is no longer the compass that directs FPC's development.  Because of that, I think the developers should consider directions that are no longer associated with Delphi at all.  IOW, design that is Pascal in spirit but no longer Delphi.

The point I'm carefully leading to is, there are a significant number of very useful and very desirable features in other languages that can be implemented in a Pascal way that would be wonderful to have in FPC and would set FPC apart, not just as a Delphi compatible language but, as its own Pascal implementation.

Doing something like that requires a well thought out, well structured mechanism to decide which features will be included and how they will be implemented. No willy-nilly stuff, otherwise it is the seed of a mess.

That's what I'm really trying to find out, is there some thinking along those lines taking place among the FPC developers or will the design of the language remain a somewhat casual process ?.



« Last Edit: June 11, 2019, 08:08:46 pm by 440bx »
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
IMO, there should be an individual or group of individuals who have a vision of where FPC is going as a flavor of Pascal and not just as a mostly "Delphi compatible" implementation of the language.

That is exact the mentality that got us all of the junk expansions.

Quote
It's fairly obvious that, at one time, Florian (and possibly others) had a clear vision of what FPC was supposed to be and where it was going, which was, providing a Turbo Pascal/Delphi compatible implementation of the language.  As Borland/Inprise/Embarcadero fiddled with the language definition in ways that were "questionable", that goal became, justifiably, less desirable.

No, the old core people simply got old, and bowed to pressure of newcomers that directly want to implement new language features.

In the old days, people would have to have at least done years of allround core work to qualify for that. That encouraged a certain sense of realism wrt language features.

That said, back then it was easier to be allround since the project was smaller and more overviewable.


« Last Edit: June 11, 2019, 08:21:52 pm by marcov »

440bx

  • Hero Member
  • *****
  • Posts: 3944
IMO, there should be an individual or group of individuals who have a vision of where FPC is going as a flavor of Pascal and not just as a mostly "Delphi compatible" implementation of the language.

That is exact the mentality that got us all of the junk expansions.
That's what a formal/structured approach to the design of the language would prevent: the addition of junk. I don't like junk features anymore than you do.

No, the old core people simply got old, and bowed to pressure of newcomers that directly want to implement new language features.
Maybe but, it could also be simply driven by a desire to prevent giving the impression that the language is languishing because no new features are added to it.  I have a feeling that's mostly what the addition of inline variables is all about with Delphi.

That said, back then it was easier to be allround since the project was smaller and more overviewable.
You're right about that, FPC is no small project anymore.  That's one of the reasons I feel a more formal method and clear vision are necessary.

There are lots of ways FPC can be made even better than it is but, it's important to avoid ending in hell while paving the road with good intentions.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
I forgot two other things.

Very long ago I wrote this about language extensions: https://www.freepascal.org/faq.html#extensionselect

And while not all developers agreed 100%, the central tenet of that, "it must make things possible that are not possible now" must be clear. Short syntax only is not desirable.

I don't think I have seen an NEW interesting new language feature in years.

kupferstecher

  • Hero Member
  • *****
  • Posts: 583
In my opinion the feature list is already too long. It's nearly impossible to know all the possibilities, the syntax options and all side effects of the various features of fpc.
So instead of introducing new features I would suggest to do some tidy up.
E.g.
- The writable typed constant concept as local static variable is counter intuitive, perhaps constants should never be variables.
- Classes, objects, advanced records. Thats one to much.
- Modula-2 syntax for blocks: if ... then ... end; for... do ... end;
- Passing constant values to var parameters should be possible. (Well, this would be backward compatible)
- Parameters as var, out, const, constref... perhaps this could be done better.
- Volatility (I know it was introduced, but as I understand if the compiler really builds on it, this would break existing code)

These are just examples, don't need to discuss them. I also know that there are very good reasons why it is done the way it currently is. Furthermore, breaking backward compatibility is a huge step.

But still I think this, a new dialect, would make the language much more modern than adding random features.
Probably, though,  its not possible to be realized with the existing resources.

440bx

  • Hero Member
  • *****
  • Posts: 3944
Short syntax only is not desirable.
I definitely agree with that.

I don't think I have seen an NEW interesting new language feature in years.
There are plenty of _OLD_ very interesting language features that would fit very nicely in FPC.

The best feature a language can offer is the writing of code that is easy to understand while being able to flag programming errors at compile time.

That's one of the characteristics of Pascal and it can be made even better.

As far as interesting new features are concerned, I think you should get out more. ;)  One of the things that seems to have dawned on some MS programmers is that a program can be created by _describing_ it instead of programming it.  The increase in productivity is quite substantial but, at least at this time, the loss of performance is too high for the method to be implemented beyond user interfaces.

It's a little bit like SQL. You describe the set of data you want, you don't write code to build the set, you just describe it and let the SQL engine figure out how to build it.  Compilers could gain from that approach (which is what Delphi is based on actually but, they never developed it beyond the initial conceptualization.)


ETA:

In my opinion the feature list is already too long. It's nearly impossible to know all the possibilities, the syntax options and all side effects of the various features of fpc.
That is true.  The real problem is that there are a lot of features whose benefit is marginal or too limited.

As you said, some tidying up would be good but, the backwards compatibility requirements make that either difficult or simply not possible.

« Last Edit: June 11, 2019, 10:16:29 pm by 440bx »
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
I already think the rate of new (non compatible) syntax adoption in recent years has been to high.
And I still fear the coming of "inline procedure declarations". Though I haven't followed it recently and may be wrong. If memory serves, most of those wanting this, did actually want closures. And that is what it is going to be.
Only to do closures, you do not need to declare procedures inline. Those should be 2 completely independent things. (And the inline declaration should not actually be a thing at all)... 

BeniBela

  • Hero Member
  • *****
  • Posts: 905
    • homepage
A big problem is that too many features are put in the compiler, when they should be in libraries. But the features cannot be  in libraries, since there is no support for proper meta-programming like nim/rust/perl-like macros.  For example
 
Advanced records could have been a single macro that converts all records to objects.

Enumerators/for..in are new.  C++ did not have anything like that, but Qt added its own foreach just using macros.

Or the parametrized  exit(abc) function is a compiler feature. But it could have simply been written as a macro to convert it to begin result := abc; exit; end

There is the case statement, and recently it was extended for strings.  Perl on the other hand does not have a case statement, but there is a Perl module that dynamically rewrites the code to convert a case-like statement to ifs or something.


Or strings/arrays/interfaces as different refcounted types. They could be replaced by records in libraries using (Maciej's) smartpointers.


All compiler features could be replaced by the single compiler  feature of a good macro system

440bx

  • Hero Member
  • *****
  • Posts: 3944
All compiler features could be replaced by the single compiler  feature of a good macro system
That's true but, there is a big disadvantage in using that method, which is, the code you _read_ is not the same as the code that is _compiled_.

In addition to that, you also have to deal with the macro language's "personality", e.g, forgetting to enclose a macro parameter in parentheses can lead to some very subtle, occasional, erratic, hard to track down, bugs.

I believe the programmer and the compiler should see exactly the same code.  It really tends to make things a lot easier that way.



(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Leledumbo

  • Hero Member
  • *****
  • Posts: 8746
  • Programming + Glam Metal + Tae Kwon Do = Me
All compiler features could be replaced by the single compiler  feature of a good macro system
That's true but, there is a big disadvantage in using that method, which is, the code you _read_ is not the same as the code that is _compiled_.

In addition to that, you also have to deal with the macro language's "personality", e.g, forgetting to enclose a macro parameter in parentheses can lead to some very subtle, occasional, erratic, hard to track down, bugs.

I believe the programmer and the compiler should see exactly the same code.  It really tends to make things a lot easier that way.
Indeed this is why I avoid macro driven language. It looks cool in the beginning, but quickly becomes nightmare when it comes to maintenance. However, Nim style macro is acceptable to me, as it works at syntax tree level (tree node manipulation) as opposed to source code level (string -> string tranformation), thus reducing the misleading error messages and such. The problem, FPC syntax tree was not designed for that since the beginning, as how Nim one was designed from the start.

440bx

  • Hero Member
  • *****
  • Posts: 3944
Indeed this is why I avoid macro driven language. It looks cool in the beginning, but quickly becomes nightmare when it comes to maintenance. However, Nim style macro is acceptable to me, as it works at syntax tree level (tree node manipulation) as opposed to source code level (string -> string tranformation), thus reducing the misleading error messages and such. The problem, FPC syntax tree was not designed for that since the beginning, as how Nim one was designed from the start.
There are a number of things I like about Nim (disclosure: I only have a passing familiarity with the language) but, I think of Nim as a macro language itself since it doesn't compile to native code, it produces C. 

I can't help thinking of such a setup as two (2) potential sources of problems instead of just one (1). 
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

 

TinyPortal © 2005-2018