[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
project.
> 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
well.
> 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;
DoDi
More information about the fpc-devel
mailing list