[fpc-devel] Modernising Pascal

DrDiettrich drdiettrich at compuserve.de
Wed Feb 23 02:54:11 CET 2005

Jamie McCracken wrote:

> 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.

I'd suggest Oberon or a similar language. I know that some companies
would use Oberon, if only that system/language came with an interactive
debugger. These companies are willing to spend real money for a
modernised Oberon system.

I never really used Oberon or Modula myself, due to problems with the
systems in those old days, but an implementation shouldn't be a real
problem these days. I also would be interested in contributing to such a

> My main gripes with Delphi/pascal is its additional verbosity and
> somewhat tedious coding practices which seem superfluous in some cases.
> 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.

IMO the best solution for (almost) all of your problems were garbage
collection. GC is part of Oberon, and it would fit into .NET/DotGNU as

> 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.

In a GUI a management overhead is acceptable, in other classes IMO it's
not a good idea: the management costs time and requires rigid design
rules, what makes it not very convenient and safe to use.

> no longer be a need for having loads of try..finally statements

GC ;-)

> 2. For Each. Its in Delphi 2005 and every modern language implements it.

Might be found in Oberon?

> 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. Base types are dynamically allocated and reference counted
> so theres no need to explicitly create or destroy them.

Some people will kill you for introducing additional implicit
try-finally blocks ;-)

Again: GC, everything else is a matter of the class library.

> var strlist : Stringlist;
> begin
>    strlist.add('mystring');
> end;

Perhaps a simple extension:
var strlist: new {T}Stringlist;


More information about the fpc-devel mailing list