I've got some things I like to see implemented in free pascal.

The first thing is the possibility to let units
include eachother. This is rather useful to code in a structured way in oop. For example suppose there's a class TMain, which has a child of type TChild. Of
course this child wants to know its parent by its type and the other way round. I want to split up my code so that the units don't become too big, so child and
parent are declared in different units. So the
situation is as follows:

{ t1.pas }
unit t1;
uses t2;
interface
type
  TMain = class
    Child: TChild;
    .
  end;
implementation
.
end.
{ t2.pas }
uses t1;
interface
type
  TChild = class
    constructor Create(owner: TMain);
    .
  end;
implementation
.
end.

Compiling t1.pas yields a circular unit reference
error. A solution is typecasting, but isn't very nice. The real solution is to allow circular unit references in unit interfaces as well.
------------------------

The second feature request is the usage of identifiers while they're defined later on in the code. For
example, sometimes is looks more natural if some
procedure is defined before another one. Defining
procedures forward is a solution, but it would be
easier if this wouldn't be necessary.
------------------------

Third:
- dynamic arrays (var a: array of integer;)
- Variants
- out arguments (ie procedure p(out a: integer); ) like in Delphi

Fourth:
block local identifiers:
- if (...) then begin

    var i: integer;
    .
  end;

- 1) "with x := a[i].position.x do ..."
or better: defining identifier x at the same time
like

  2) "with var x := a[i].position.x do ..."
  or
  3) "with const x: integer = a[i].position.x do ..."
  I'd prefer construct 2) (so without mentioning x's
  type explicitly). Construct 1) where x
  is defined as a local variable elsewhere can also be

useful.

(Note: replies please to , I'm not
in the mailing list(s))

__________________________________________________ Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

You can do that already. But only if one of the two references is in the implementation section. If the uses would be in the interface section, the compiler can never decide which unit to compile first in such case, so it simply cannot be done.

Pascal is a single pass language. This is necessary for the strong type checking - hence the forward declaration. So this also is not possible.

------------------------ Third: - dynamic arrays (var a: array of integer;)

This is already possible; both in 1.0 and 1.1

- Variants

Supported in version 1.1

- out arguments (ie procedure p(out a: integer); ) like in Delphi

Supported in version 1.1

I don't think we will do this as this will lead to many nested try/finally blocks and according stack frame buildups, leading to very inefficient code.

If you want this, I suggets you use C,Perl or PHP or so. Pascal is a very structured and readable language, and I think that it should remain so. Introducing this kind of things will badly affect the readability and 'cleannes' of the language.

Michael.

On maandag, maart 25, 2002, at 06:10 , Pavel V. Ozerski wrote:

(sorry for my previous message, I clicked on a wrong button :)

Also I would remember one my non syntax-related suggestion: to use WDOSX instead GO32;

There is no "instead" necessary, both can be supported without any problems (just like we supported both go32v1 and go32v2 for a while)

Jonas

Hello all,

I'm sure all these suggestions have good intentions but are based on an very bad circumstance: the language Object Pascal wich is developing by Borland, SpeedSoft, FPC team, VP team etc has no official registered standard! At result whe have a lot of syntax (not only in libraries) incompatibilities even between different versions of product developed by the same team! I'm sure, Object Pascal is an independent language which differs from classic Wirth's Pascal and needs to be standartized!

:) in spite of this, I cannot restrain myself and would also suggest some syntax improvements but they at least seem to be not conflicting with Pascal ideology: To make possible access to overriden types, variables etc in nested functions/procedures and in "with" blocks:

procedure proc1;
 var
  i:integer;
 procedure proc2;
  var
   i:integer;
  begin
   for i:=proc1.i to 10 do
........................
program MyProg;
var
 R:record
  x:integer;
 end;
 x:integer;
begin
 with R do
  x:=MyProg.x;
..........................
Also I would remember one my non syntax-related suggestion:
to use WDOSX instead GO32;

compiler: FPC 1.0.4
target: go32v2

1:   var
2:      b: byte;
3:   begin
4:   b := 0;
5:   b := NOT b;
6:   end.

Switch range checking ON compile and run.
You will get:

Runtime error 201 at line 5

But that's not the behavior I would have expected. I think this is a bug.

Regards Peter

Good day for you, Peter!

Wednesday, April 10, 2002, 2:10:18 PM, you wrote:

PB> 1: var
PB> 2: b: byte;
PB> 3: begin
PB> 4: b := 0;
PB> 5: b := NOT b;
PB> 6: end.
PB> Switch range checking ON compile and run.
PB> You will get:
PB> Runtime error 201 at line 5
PB> But that's not the behavior I would have expected. PB> I think this is a bug.

Yes, this is a bug and it is already fixed in snapshots. You may download latest snapshot from
ftp://ftp.freepascal.org/pub/fpc/snapshot/

or wait for 1.0.6 release.

To Peter Vreman: That distribs what is placed on /dist/%os%-1.0.6/ is release or pre-release (or beta)?

-- Someone who loves to program and enjoys being clever about it

Hmmm, not really. FPC does all evalutation of ordinal expressions with the natural integer size of the CPU thus everything is evaluted as 32 Bit => NOT b eavlutes to $ffffffff which doesn't fit into a byte.

This behavior is different to good old TP but it is conform with ANSI-Pascal standard. I did this decision 9 years ago when a started FPC, maybe it was wrong but
in a lot of cases it makes the expression evalution more logical.

Good day for you, Florian!

you wrote

>Runtime error 201 at line 5 >But that's not the behavior I would have expected. >I think this is a bug.

FK> Hmmm, not really. FPC does all evalutation of ordinal expressions with the FK> natural integer size of the CPU thus everything is evaluted as 32 Bit => FK> NOT b eavlutes to $ffffffff which doesn't fit into a byte.

FK> This behavior is different to good old TP but it is conform with ANSI-Pascal FK> standard. I did this decision 9 years ago when a started FPC, maybe it was FK> wrong but in a lot of cases it makes the expression evalution more logical.

I don't think so. I think the result of operator should have same type as an argument of operator. If we need different type - we shall use type modifier ( not longint(b) ). Maybe exception is the case when specified const value, i.e. for example (not 0) - there result type is undefined.

BTW, what if we using type bigger than integer size of the CPU? I tested this and

var
  qw:qword;
begin
  qw:=0;
  writeln(not qw);
end.

In 1.0.4 program just written me character "/". Why it so - I don't know. But 1.0.5 report me result that more similar to true: 18446744073709551615.

Anyway, in the snapshot (at least 1.0.5 [2001/12/16] for i386) it seemes to work exactly as I offer. Just don't change anything! ;-)

-- Someone who loves to program and enjoys being clever about it

or wait for 1.0.6 release. To Peter Vreman: That distribs what is placed on /dist/%os%-1.0.6/ is release or pre-release (or beta)?

pre-release to test the installation and compiler. The compiler shows 1.0.6-beta on the screen.

But the other logical operators (AND, OR, XOR ... ) don't have this problem. No one of them causes a range check error when used on byte-variables and range checking is active.

Regards Peter

That's because they don't generate a value that's out of the byte range. If you do

b := b xor $5;

then the whole expression is still evaluated as a longint, but the result will lie in the range of a byte, so no range check error is generated (there is still range check code generated, but it doesn't fail).

Jonas