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 ?
[I already think the rate of new (non compatible) syntax adoption in recent years has been to high.I agree.
I don't think so (but I don't want to argue about it.)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.
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.
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.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.
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.
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.
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.
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.
All compiler features could be replaced by the single compiler feature of a good macro systemThat'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_.
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.All compiler features could be replaced by the single compiler feature of a good macro systemThat'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.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 think the recent discussions on fpc-devel showed that we're still not accepting everything and the kitchen sink. ;)QuoteIs 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".
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.No. Just no. Both compatibility to TP/Delphi and backwards compatibility are important core concepts of FPC (though the Delphi compatibility got quite a chink with Delphi introducing inline variables %) ) and thus we won't restructure core concepts only because some think that it's too much. Those people can always start a new compiler, cause that's what it would be essentially.
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, I think of Nim as a macro language itself since it doesn't compile to native code, it produces C.If you take a look at the generated C code, or how it's generated, it's far from other compilers that transpiles to C, where the C code is usually still human readable. The author treats C like an abstract architecture, hence the generated C code looks more assembly-ish than C converted code.
I'm not familiar enough with Nim to evaluate it properly but, the fact that a separate compiler is involved in the process of getting executable code makes me uncomfortable. That additional compiler is, at least potentially, another source of problems.but, I think of Nim as a macro language itself since it doesn't compile to native code, it produces C.If you take a look at the generated C code, or how it's generated, it's far from other compilers that transpiles to C, where the C code is usually still human readable. The author treats C like an abstract architecture, hence the generated C code looks more assembly-ish than C converted code.
I'm not familiar enough with Nim to evaluate it properly but, the fact that a separate compiler is involved in the process of getting executable code makes me uncomfortable. That additional compiler is, at least potentially, another source of problems.Indeed, it was a source of attraction by supporting multiple C compilers. It actually has more than 1 backend, the compiler can generate C, C++, Objective-C and JavaScript. Much like FPC with HL codegen backend only plus Pas2JS.
Well, the only thing I really miss is anonymous methods because I have a lot of dual code base between Delphi and FPC.
But that is already in progress.
And gettypekind in generics.
And note: the way Delphi does it with hidden interfaces is not optimal.
Although notationally easy it has a performance hit.
I'm pretty sure it works in generics at least in trunk. You can't currently use it in constants or within scanner conditionals though, which you can in Delphi. That said, I actually have a patch I've been working on that enables this, and also adds Delphi-compatible IsMangagedType and IsConstValue intrinsics that I might submit soon. (FWIW, adding those intrinsics was actually... very easy, as the compiler has internal methods that provide basically exactly the required functionality.)
The specialization time elimination is already done by the compiler if it can do it (so once IsManagedType and IsConstValue are supported that should be immediately picked up as well; GetTypeKind already does that correctly, cause I explicitely tested that):I'm pretty sure it works in generics at least in trunk. You can't currently use it in constants or within scanner conditionals though, which you can in Delphi. That said, I actually have a patch I've been working on that enables this, and also adds Delphi-compatible IsMangagedType and IsConstValue intrinsics that I might submit soon. (FWIW, adding those intrinsics was actually... very easy, as the compiler has internal methods that provide basically exactly the required functionality.)
My bad. I indeed meant ismanagedtype and not gettypekind and specialization time elimination of other branches
.section .text.n_p$thelloworld_$$_test,"x"
.balign 16,0x90
.globl P$THELLOWORLD_$$_TEST
P$THELLOWORLD_$$_TEST:
# [42] begin
pushl %ebp
movl %esp,%ebp
leal -24(%esp),%esp
# Var u8 located at ebp-4, size=OS_8
# Var u16 located at ebp-8, size=OS_16
# Var u32 located at ebp-12, size=OS_32
# Var u64 located at ebp-24, size=OS_64
# [43] specialize GenSwapEndian<UInt8>(u8);
movb -4(%ebp),%al
# [44] specialize GenSwapEndian<UInt16>(u16);
movzwl -8(%ebp),%eax
shrl $8,%eax
movzwl -8(%ebp),%edx
shll $8,%edx
orl %edx,%eax
# [45] specialize GenSwapEndian<UInt32>(u32);
movl -12(%ebp),%eax
shll $8,%eax
andl $-16711936,%eax
movl -12(%ebp),%edx
shrl $8,%edx
andl $16711935,%edx
orl %edx,%eax
roll $16,%eax
# [46] specialize GenSwapEndian<UInt64>(u64);
pushl -20(%ebp)
pushl -24(%ebp)
call SYSTEM_$$_SWAPENDIAN$QWORD$$QWORD
# [47] end;
movl %ebp,%esp
popl %ebp
ret