New language features?

[Rinzwind]

There has been a patch for multiline strings (using back ticks) which has gone ignored for 4 years I believe. I can't understand how this is possibly being rejected since it's so obviously useful and battle tested in so may other languages. yes I know the white space etc... but many use cases are for nested code like SQL, GLSL where whitespace doesn't matter so there's literally no downside.

Because the maintainers are way too conservative and do not want any change. Same can be seen in the IDE where a default docked mode (or clear user choice at first start) would make much more sense. Also global instant auto completion doesn't seem to be tested because when it is open a spacebar press (and many other special characters) selects the hilite instead of going on manually entering the code line. Or instant capitalization correction after completing a word. They are just not interested in attracting new users. There are also simple things like the terrible help font in many places (times new roman?). I have no idea who is actually in control of FreePascal and Lazarus. Is there a committee where stuff is discussed and decided upon? Any vague road map/ideas for future? Website could use a modern paint too. Anyway, still many thanks for all your efforts obviously. Wish you lead the way for modern Pascal.

[Awkward]

Because the maintainers are way too conservative and do not want any change.

Or because this featue break pascal rules (compatibilities), is not so important and  don't needs for most programmers/most cases.

[Thaddy]

Modern Delphi (12+) has multi-line strings, so that feature may be implemented in the future in a Delphi compatible way.
The Delphi syntax is like this:

Code: Pascal  [Select][+][-]

1. writeln('''test
2.            me
3.            multi
4.            line''');

which makes more sense than the back tick.
Maybe the existing code can be adapted to use that syntax. I have been playing with the freepascal version and indeed it is very useful: think xml, json, etc

[Ryan J]

Because the maintainers are way too conservative and do not want any change.

Or because this featue break pascal rules (compatibilities), is not so important and  don't needs for most programmers/most cases.

breaks nothing. What are you talking about? ''' vs ` is irrelevant. I don't see a difference to either except backticks is less characters.

[Bart]

[I have no idea who is actually in control of FreePascal and Lazarus. Is there a committee where stuff is discussed and decided upon? Any vague road map/ideas for future?

The FreePascal and the Lazarus devlopers ar all volunteers doing this in their spare time.
None of us gets paid.
And the core team does not consist of that many devels.
So, we never have enought time of enough manpower to implement all that we want.
This also makes that we tend to implement, fix, improve the things that we care about, or what we need.
So, certain usefull features, may very well not be high on the priority list of any of the devels.

Also, the compiler devels should be "conservative", in such a way that backwards imcompatibility or breaking existing features is a real danger.
And unfortunately (due to lack of resources) the release cycle of fpc is quite long, so a bug in the released compiler will be there for a long time.

I'll let the fpc devels speak for themselves, but adding features form whatever language is not going to attract new users, it will only make the language less Pascal.
Personally I very much dislike the fact that we allow C-operators.
Pascal is, by design, a verbose language.

Last but not least: developing fpc and Lazarus is not a democracy.

Bart

[Martin_fr]

Last but not least: developing fpc and Lazarus is not a democracy.

Actually it is... It is just that most people forget that a democracy needs people who serve (occupy an office).  The office here is NOT just to write code, but also to provide/release.

So anyone can run for office, simply by creating a fork an maintaining it.

Then the people can exercise a democratic vote, and decide if they use the original or the fork. And if the majority starts using the fork, then that effectively becomes the lead.

[Bart]

Last but not least: developing fpc and Lazarus is not a democracy.

Actually it is...

But not in the sense that people can vote, and that we are obliged to do as "the people" say...

Bart

[Martin_fr]

Off topic to the fpc discussion. I'll give a short answer, if interested open new thread(s)

Same can be seen in the IDE where a default docked mode (or clear user choice at first start) would make much more sense.

1) Question of someone implementing such a setting (for the initial setup dialog)
2) Question of ensuring that (if switched off), the mere presence of the docking code does not add bugs to an undocked IDE

Also global instant auto completion doesn't seem to be tested because when it is open a spacebar press (and many other special characters) selects the hilite instead of going on manually entering the code line. Or instant capitalization correction after completing a word. They are just not interested in attracting new users.

If you mean "complete as you type" (e.g. if you type "TF" it offer TForm, without you ever pressing ctrl-space), then yes: that is probably pretty little tested. IIRC it was contributed, no idea if anyone in the core team uses it. Testing here means, users reporting bugs. And the it may even depend if someone contributes... Simple to due manpower available.

Given that each time has about 1 or 2 dozen members, but there are thousands of ways to use the many features available... Do the math, we can't test them all ourselves.

There are also simple things like the terrible help font in many places (times new roman?).

Good question. I don't use the help normally. But also never minded the font (On windows it is ok). Open another thread with examples and suggestions. And then it depends, what others think (it may be a matter of taste)

I have no idea who is actually in control of FreePascal and Lazarus. Is there a committee where stuff is discussed and decided upon? Any vague road map/ideas for future? Website could use a modern paint too. Anyway, still many thanks for all your efforts obviously. Wish you lead the way for modern Pascal.

Many of the team members are listed on the wiki. But you can also look at the lists of committees in git.

Members within each team (FPC / Lazarus) discuss some of the decisions that are needed. Some parts of the projects have dedicated maintainers within each team, and those then may decide on their own or in smaller groups (though important stuff still gets escalated)

But then there is also, what actually comes up for discussion... If no one raises an issue...

I maintain parts of the editor (synedit, not codetools), and I have come across other peoples work-flows, which I would never have thought of if they hadn't mention. I could not even have considered them, as I was not even aware of the basic idea behind it.

However, there isn't a committee that decides what *must* be done. As there aren't paid developers, non of the developers can be commanded to do a specific task.

Also mind, that for some topics you may need to go to the mail lists. Not all the core devels hang out on the forum. But to get initial responses the forum is a very good place.

[Martin_fr]

Last but not least: developing fpc and Lazarus is not a democracy.

Actually it is...

But not in the sense that people can vote, and that we are obliged to do as "the people" say...

Well, part of every democracy: You can't vote for a party that does not exist (You can chose not to vote at all). Currently there only is one party (or 2 if you count CT, and consider it different enough...)

[simone]

I have been following this forum for many years and I basically understand the philosophy that underlies the choices on language features to implement.

What is not entirely clear to me is whether today, as in the past, the main goal is still to be compatible with Delphi or not. It seems to me that this project was born over 20 years ago to be an opensource alternative to Delphi. And Delphi mode exists precisely to maximize this compatibility.

But since Delphi has recently introduced new (and questionable, I agree) features into the language like the ones described here:

https://blog.marcocantu.com/blog/2018-october-inline-variables-delphi.html

which the core developers reject on principle, as they violate the founding philosophy of Pascal, consisting of "declare before using", it seems clear to me that Delphi and FPC have taken different paths.

This is one of the main problems of object pascal: lack of standardization and proliferation of dialects... The ISO 7185:1990 and ISO/IEC 10206:1991 standards, if I remember correctly, concern classic pascal, not object pascal.

[Muus]

Well Free Pascal suffers from inertia as well, one can just look at the RTL docs that the code examples have no syntax highlighting or proper formatting, the user's guide is one massive list, the amount of switches in the languages as-is is beyond comprehension. Not only by themselves but also by how they are laid out (see attachment). Not to mention that Lazarus cant be used as an editor on its own, you HAVE to open a project and as someone who uses Castle Engine, one look at the ifndefs and switches used and any argument about "readability" and "pascal way" goes right out the window. The different amount of files .lpr,lps,lproj, .pp, .fpc, ppu, inc and fpmake, compiler magic functions and to beat the limping horse to the ground a bit; This is before you even get to the naming of the files vs the unit X; definition having to match.

Implementing what Delphi is doing like inline vars or skipping @ in callbacks or w/e can stay in Delphi but _sane_ defaults rather than {$than edge-case-for-syntax-used-10-years-ago-compat} supporting would go a long way already. The language server tooling is also lacking, although Michelis does impressive work and it's improving steadily.

But ranting on the forum is kinda pointless anyway, someone like marcov will come along and ask where my patches are but contributing means that the patch should go to a team that is amicable towards those patches to begin with, when you have the main devs already throwing the brakes on it just means whoever sent that patch becomes the maintainer and 5 years from now it'll be "old and unmaintained". Since I just lurk and see discussions like this often the core devs (or at least the ones that talk here) already sound cynical about peoples contributions do not motivate in the slightest.

One would think that if someone came with a suggestion that they'd get encouraged to contribute rather than "well where's your patch then?" attitude that tends to dominate. The contributions wont come if the motivation is lacking from the people at the top. The main page of freepascal not being updated has also been mentioned before but development activity can also be shown in the header about when the last commit was and what about. Or the latest actual version _and_ snapshot with date attached to it; maybe dont mention LLVM backend development _last_ in the paragraph after uhm, the Motorola 68K and uh, DOS; Actively hiding dev activity (on top of outdatedness) on the frontpage of a Pascal compiler that already has an inherent "oldness" bias towards it (even if unwarranted and FPC is great; theres just a few rough edges) would be the first thing to fix.

The website not having a new look, ordained and approved by greybeards on this forum by a _core_ dev nor random contributor in a decade already shows preference towards inertia.

tl;dr project intro is as outdated as a 56k modem, the rather cynical responses, no little blurbs about whats added, lack of modern documentation layout (Sphinx exists, so does PasDoc) coupled with a website from GeoCities-era does not enthuse the beginner. The derision towards previous attempts shown at times is also a headscratcher. When one can ask Drew DeVault (notoriously opionated developer) a question on IRC or email and get a paragraph back on how to contribute/where/how/what to expect it's no wonder {$Objecdelfreepascal} stagnates. The maintainers will be seen as doing just that, maintaining and it's a shame.

[Thaddy]

Every post that mentions inline vars as positive should be ignored.
Pascal is all about separation of declaration and implementation. Period.
Delphi developers decided wrong, it was a mistake. But once a geany is out of the bottle you can't roll back.
And on this forum there is a great majority who think so.
BTW if you don't like the looks of the docs add your own stylesheet and regenerate with fpdoc..

[Muus]

Person above me is an excellent example. I said "no inline vars, they can stay in Delphi" so he did not read it but responded with a hostile attitude.

[Thaddy]

I read it and I do not agree with 99% of it.

[Ryan J]

Every post that mentions inline vars as positive should be ignored.
Pascal is all about separation of declaration and implementation. Period.
BTW if you don't like the looks of the docs add your own stylesheet.

Maybe inline vars are the not the solution but the fact Pascal lets you access uninitialized memory outside of the scope in which it's allocated is a design flaw of the language. Because declaration and assignment are disjointed you can never be sure if the memory is actually initialized or not. This is a huge source of potential bugs and crashes. It would be nice for example if you could have pointers which were non-nullable but the design of Pascal prohibits this.

New programmers which are learning on memory safe languages are going to notice this and keep away from Pascal. Even the idea of declaring a variable outside the scope in which it's used is very strange compared to all other languages and it's hard for me even to justify why it's helpful to a declaration so far away from where it's actually used. I'm sure many people have switched away from Pascal for this reason.