[fpc-devel] Modernising Pascal
Marco van de Voort
marcov at stack.nl
Wed Feb 23 06:56:53 CET 2005
> Just wandering if any of you are interested in modernising Pascal which
> is looking quite dated when compared to modern languages like Python. I
> note free pascal supports a variety of pascal dialects but none of them
> are particular modern.
Could you define modern? Nearly all "modern" languages seem to leverage
early seventies C syntax, except Python of course, which, as Florian already
adeptly remarked is more a sixties syntax.
> My main gripes with Delphi/pascal is its additional verbosity and
Ah, verbosity is one of the things I actually like about it.
> somewhat tedious coding practices which seem superfluous in some cases.
.... because it saves bugs, and costly debugging.
> Now I dont mind typing a bit extra to make code cleaner and more legible
> but I have a few ideas which would reduce needless typing and improve
> clarity at the same time.
>
> (feel free to shoot down any of these ideas)
>
> 1. Memory management. Delphi is quite incosistent here by allowing
> component classes to be auto managed (via their owner) whilst
> non-component class have to be manually managed.
They are not really auto managed, nor refcounted. They simply exist for the
near entire life of the program (except startup and shutdown), or are manually
created.
> The best solution I can
> think for this is to reference count non-component classes. This should
> be safe for TObjects but obviously not for Tcomponent descendants (cf
> circular reference problem) so a protected variable could be added to
> TObject to specify whether to ref count it or not (with TComponent
> turning it off).
This is impossible. 90% of the language wouldn't work anymore as it does
now, and besides, it would be dog slow. Could be that it gets slower than
Boehm GC even.
> This will improve legibility of code too as there will no longer be a need
> for having loads of try..finally statements to free stuff.
How do you free objects then? Those try..finally's are there actually because
of the refcounting.
> 2. For Each. Its in Delphi 2005 and every modern language implements it.
Yeah, and I still wonder why. There is nothing to gain with it.
> 3. Increasing the number of base types to include common stuff like
> lists (Tlist, TStringList). Python does this nicely and theres no reason
> Pascal cant.
I partially agree with you that the container types of Delphi aren't the
strongest point. However the solution is to make a lib with better types.
Pulling it in the compiler with ref counting however is something totally
else, and will make them dog slow.
Keep in mind that I can walk through 5-6 million (real world) objects in
just under 2 secs in Pascal/Delphi on an already old 2GHz P IV, and inspect
them all. Try that in Python.
More information about the fpc-devel
mailing list