Three things needed in FPC:

1) Garbage collection. Anybody who's worked on apps with objects of objects of objects of objects will see the value in this. If CMEM is used, can the Boehm garbage collector be used? Even a resurrection of the split-heap stuff into something more generalized (mini-heaps) could help here.

2) Contract programming. We have to be able to show proof of correctness in code to prove the business value of FPC. This will be a major theme for the business side of software development in the future.

3) A new concurrency model. Multi-core programming adds a layer of complexity, plus the future of computing is all about where I can buy or steal a unit of computing power for my app.

Ok, one more: 4) I miss array slice syntax (str:= s[2..7];) from the Stony
Brook M2 days. So much more concise than Copy().;

2) and 4) could probably be handled by pre-processing. Anybody else thought about this stuff?

James

Hi,

I'm talking from my own knowledge and experience, and not in behalf of anyone else...

As a Java developer, I can say that GC is one of the worse things ever invented ... The reason is simple, you never can force the GC to take place (you can try, but it will not work all of the time), but if you already know when you want to free the objects, why not just free the object in the first place ?!
Another good practice is to free every created object, so I really do not understand why we really need to have this, however if there will be a good argument, I might agree.

2) Contract programming. We have to be able to show proof of correctness in code to prove the business value of FPC. This will be a major theme for the business side of software development in the future.

I believe that by changing the name to something catchy, and to make some marketing for the "new" language (and some new buzz usages for it) will create a much better effect. This Friday, I was at an open source conference, and when I mentioned the word "Pascal" people wanted to move along to a new subject... there is no problem with the language... only with the way it feels for some people.

3) A new concurrency model. Multi-core programming adds a layer of complexity, plus the future of computing is all about where I can buy or steal a unit of computing power for my app.

Sounds good for me, when do you start working on this one ? ;)

Ok, one more: 4) I miss array slice syntax (str:= s[2..7];) from the Stony Brook M2 days. So much more concise than Copy().;

Let me please quote Marco and say "this is a synthetic sugar", or at least sort of.. it's not like there is no way (without creating your own function) to do this... but if you really want, please write all the pro and cons about it, and if people will think that the pro's are better then the cons' I sure that more people will agree...

Ido

Op Sun, 12 Aug 2007, schreef ik:

It is supported in FPC 2.2. The reason to support it is not the syntactic sugar aspects, but to allow passing dynamically allocated memory.

I.e. if you have a:

procedure sort(var a:array of word);

... and some dynamically allocated memory, a call to sort can be done like:

var p:Pword;
begin
  getmem(p,2000*sizeof(word));
  {.......}
  sort(p[0..1999])
end;

As there is no other way to do this, array slices are a usefull addition to the language. It also looks like they will allow better optimization in the future, because the compiler knows more information in advance, like wether the ranges can overlap or wether the data to be moved is already aligned.

Daniël

JK Smith at Grid-Sky wrote

Ok, one more: 4) I miss array slice syntax (str:= s[2..7];) from the Stony Brook M2 days. So much more concise than Copy().;

One thing I *really* love about Python. No, really!

Brad

ik wrote

source conference, and when I mentioned the word "Pascal" people wanted to move along to a new subject... there is no problem with the language... only with the way it feels for some people.

I can't agree more. It is actually funny seeing peoples expressions when they here the word 'Pascal' in the name. This is a huge downfall and probably why Borland decided to call their implementation Delphi. Trying to break the association with Pascal!

Regards,
- Graeme -

I don't know if anyone has tried this, nor what the exact requirements are for the Boehm garbage collector to work. An llvm code generator backend will allow garbage collection to work (at least if you don't mess around too much with assembler, I suppose), but it's still quite far off.

Even a resurrection of the split-heap stuff into something more generalized (mini-heaps) could help here.

Garbage collection means that the system relieves you from the memory management mess, and that you cannot get things like double free errors or using pointers are they have been freed. Split heaps on the other hand are still manual memory management and therefore still have similar downsides (and upsides) as other manual memory management techniques.

So I don't really see the relation. Even though it may seem at first sight that you do not have to bother with individual objects in case of split heaps, in practice you do because you have to make sure that no pointer to any of those objects can escape beyond where you free the split heap.

2) Contract programming. We have to be able to show proof of correctness in code to prove the business value of FPC.

Tom Verhoeff and some of his students are doing some work on pre/ postconditions in a separate branch of FPC.

This will be a major theme for the business side of software development in the future.

That remains to be seen.

3) A new concurrency model. Multi-core programming adds a layer of complexity, plus the future of computing is all about where I can buy or steal a unit of computing power for my app.

This has been mentioned by many people before you, but it is quite difficult to actually come up with such a model which is both easy/ intuitive and correct. Feel free to add your own proposal.

Note that extremely unlikely that things will happen just because you say/think they are important. In most commercial project it depends on whether you represent a lot of money which threatens to disappear if your requirements are not met, because money is the primary value there.

In non-commercial projects, contributors/maintainers are the primary value, and thus actually submitting something rather than saying what should be done in your opinion is most likely to have any positive effect (there is no shortage of people with great ideas about what we should spend our time on).

Jonas

I tried this long back (~ 4 years ago) and the collector did seem to work atleast on windows. It crashed on Linux everytime though. I think it has got to do something with adding roots to the collector. I had posted about this in the then FPC forums (is it still working?).

Cheers,
-Krishna

Here's the link to the post I made in 2002:

http://community.freepascal.org:10000/bboards/message?message_id=115034&forum_id=24088#117077

Cheers,
-Krishna

Actually, we (at Dept. Math/CS of TUE) have already contributed an experimental branch to the repository for this. See branches/tue. That project is in a stable state, ready to be merged (since January). It is not finished (still a number of missing features).

I am to blame for the delay in taking follow-up actions; my apologies.

Documentation can be found at (in formann.zip, but also is also unzipped)

<http://www.win.tue.nl/~wstomv/software/formann/>

Basically, the current features are available (see user.pdf).

It is possible to insert assertions before, between or after any statement, using {@ ...} syntax. These are (optionally) compiled just like regular Assert()-statements. Furthermore, pre- and postconditions of functions, procedures and methods can be given. Class invariants are supported in a limited way. Before loops the programmer can insert an invariant and a variant function. Finally, there is support for propositions and definitions, that act as abbreviations.

Missing are the abilities to use quantified expressions like 'for all', inheritance of class invariants, and giving pre- and postconditions of procedures and functions in the unit header instead of the unit implementation.

...

By default, formal annotation parsing is switched off. This is to maintain backwards compatibility with programs that have comments that start with The FreePascal compiler itself has at least one place where a comment starts with

To control the behavior of the compiler with respect to formal annotation parsing, two options are made available: compiler directives and command-line arguments.

The command-line argument -Sf switches formal annotation parsing on.

The compiler directive {$FORMAL+} switches formal annotation parsing on, {$FORMAL-} switches it off.

The directives take precedence.

(Please note that some formal annotation constructs make the compiler generate run-time assertion checks. These are not compiled into actual code if assert()-statement compilation is switched off.)

	If the argument -Aproofobl is given on the command-line, then
	proof obligations for procedures and functions with pre- and
	postconditions are generated (if feasible), as a LaTeX file.
	(Two examples arincluded: naive.pdf, intelligent.pdf.)

The file programmer.pdf contains information for developers; it documents how things have been implemented.

Maybe a developer can take a look, and we can discuss off-line whether to merge this, and if so, how to proceed.

Best regards,

Tom

The issue is to provide some relief from leaks caused by heavily object laden applications written by programmers who know how to write objects, but don't know how to free them. If I'm sure of the scope of a group of objects, and also that one or more are leaking, then I could at least stop the leak in the short term by a mark and release.

At any rate, I've found that while you or I might be very diligent at explicitly freeing resources, on a complicated system, some programmers simply are not, and we have to work with these programmers.

> 2) Contract programming. We have to be able to show proof of That remains to be seen.

This is the business side of software development which you may or may not be interested in. My concern for Contract Programming is based on a couple of issues we can certainly argue about, but I'm fairly certain that the future is going to unfold this way:

1) Internet is the emerging platform. The OS is just another background process.
2) Buggy applications are tolerated because they run on each "personal computer" island. User experiences with bugs are insulated.
3) Make the same app an internet process, and now bugs affect more users from fewer points of failure. Even trivial internet apps become mission-critical.

The point is, the traditional software warranties won't be tolerated by business in the future. We have to carry responsibility and liability for our work, so we have to come up with techniques that prove "due diligence" that we've done everything we can to build our applications in an **accountable and auditable way**.

Programmers at Lockheed turn their car keys over to test pilots. If an accident happens due to software, and provided the test pilot is still alive, the test pilot gets the car.

That's an extreme example of a person's life on the line because of a programmer's work, but as the internet is exploited more and more as the platform it should be, the lives of lots of businesses will be affected in a serious way. Given two competing applications with matching metrics, the application that provides built-in accountability will get the job. This isn't a programming issue like whether we should support generics or whatever new language feature. It's a business issue.

This has been mentioned by many people before you, but it is quite difficult to actually come up with such a model which is both easy/ intuitive and correct. Feel free to add your own proposal.

Just putting out feelers and would love to contribute to such a project. But I think it's a hell of a lot more important than just talking about it as a buzzy or fashionable concept. It's got to happen before the internet can be fully realized.

I'm under no illusions about that. I am convinced that these are necessary projects for the future though. To imply that it is unlikely that they won't happen just because I think they're important simply means that you aren't convinced of their value. Respectfully, I believe you'll change your mind on this in the future.

I can appreciate that, and I'm sure you guys who have done a brilliant job are tired of being hounded for new requests for years. I just wanted to gauge community interest.

James

Daniel had mentioned your work in a community post. Thanks for the effort, and I'd love to try it out. And thanks for that detailed post.

James

It is supported in FPC 2.2.

Sweet!

It mainly means that I have plenty of other, imho at least equally important, things to do already :) Such as fixing bugs in the codebase which is already there (which keeps growing and therefore requires more and more maintenance, especially since the number of developer hours available does not grow with it at a similar pace), adding support for Objective Pascal (needed to remain viable on Mac OS X), and adding support for LLVM (needed to support many different processors which we otherwise can never properly support, and also nice to profit from other's people work on low level optimizations).

Jonas

It seems to me, if you have the latter, you don't need the former.

<rant about personal distaste concerning GC deleted as pointless>

Jeff.

Real world need for DbC, or some way to show due diligence:

http://www.lightbluetouchpaper.org/2007/08/10/house-of-lords-inquiry-personal-internet-security/

Quote:

"The third area, and this is where the committee has been most far-sighted, and therefore in the short term this may well be their most controversial recommendation, is that they wish to see a software liability regime, viz: that software companies should become responsible for their security failures.....

"and in practice it may be a decade or two before there�s sufficient case law for vendors to know quite where they stand if they ship a product with a buffer overflow, or a race condition, or just a default password...."

Competitive advantage to be exploited here.

James