Hello FPC developers

I've been using Algol-like languages since the times of Algol '60. In general I'm rather happy with FPC, but I miss a feature which I found in Intel's PLM languages. I'd like to submit it to see if there's a chance it could be introduced in FPC.

The feature is the *based* construct, which makes IMHO typed pointers much easier to deal with. It makes the code easier to write, more readable, and shouldn't break anything existing: it would be a language extension, which, in my incompetent judgment, should be fairly simple to implement. Those who don't like it could just avoid using it, and continue the old way.

For those unfamiliar with PLM, the construct in FPC could like that:

var
   Pfoo: pointer;
   foo: "any valid FPC Type" based Pfoo;
or
   foo: based Pfoo "any valid FPC type";
.....
   Pfoo := APointer;
   foo := Whatever;
   WhateverElse := foo;

This would make Pfoo an untyped pointer, while any occurrence of foo would be replaced by the compiler with a Pfoo^, typed unambiguously by foo type.

Multiple declarations are allowed such as:

var
   Pfoo: pointer;
   Bfoo: byte based Pfoo;
   Ifoo: Integer based Pfoo;
....
implementation
....
   Pfoo := ABytePointer;
   Bfoo := WhateverByte;
....
   Pfoo := AnIntegerPointer;
   WhateverInteger := Ifoo;

This becomes particularly handy when the fpc types more complex, such as different record types.

Currently, to achieve the same result you need to write more, without adding to readability and maintainability, but perhaps adding something to obscurity instead:

type
   PByte: ^byte;
   PInteger: ^Integer;
...
var
   Pfoo: pointer;
   PBfoo: PByte absolute Pfoo;
   PIfoo: PInteger absolute Pfoo;
....
implementation
....
   PBfoo := ABytePointer;
   PBfoo^ := whateverByte;
...
   PIfoo := AnIntegerPointer;
   whateverInteger := PIfoo^;

Something of the sort is already done with objects or strings where the pointer declaration is implicit. This construct would extend the same logic to all other types, but with an explicit declaration of the pointer.

It would, IMHO help to get rid of some of the obscurity inherited by the C language constructs.
This would also help to get rid, of the ambiguities (also inherited for C) where a variable name sometimes means the value, sometimes means the pointer, depending on context.

Any opinion?

I don't see the difference between "based" and absolute, except order of keywords?

Micha

Micha Nelissen ha scritto:

With "based" you declare a variable name, which you access directly, without need of an extra type declaration. Pfoo is the pointer, foo is the variable, no ambiguity.

With "absolute" you need a) to declare an extra type (PByte, or whatever), b) to explicitly access the variable through the pointer (PBfoo^ as opposed to foo). But if the variable is an array or a string, then you have ambiguities wether Pfoo means the variable or the pointer.

Order of keywords of course is not relevant, I just picked up the first one coming to my mind.

Giuliano Colla wrote

With "absolute" you need a) to declare an extra type (PByte, or

"Declaring an extra type" is one of those things that make Pascal what it is; declaring before use.

whatever), b) to explicitly access the variable through the pointer (PBfoo^ as opposed to foo). But if the variable is an array or a string,

So we're talking about saving typing of a '^' ? Explicitly typing a '^' when you're derefencing a pointer makes the code more readable, not less.

Micha

On Mon, 16 Nov 2009 12:17:23 +0100, Micha Nelissen wrote about Re: [fpc-devel] Could FPC add the PLM "based" construct?:

The "based" keyword actually comes from PL/I, which Intel used as the basis for PL/M.

The way based variables work is that they are always accessed via a pointer, but the pointer is always type-neutral. This means that the access to the addressed storage location is determined not by the pointer, but by the based variable (usually a structure).

This, in turn, means that one can declare multiple structures associated with just a single pointer, each causing the compiler to generate code specific to that structure. The benefit is that there can be some indicator that tells the application *at run time* what type of structure the pointer is addressing, and the appropriate code to access the data can be executed.

The synopsis is that an untyped pointer becomes like a hardware "base register", which is the way pointers are meant to be.

Note that PL/I also has type-associated pointers, called a "handle" for the associated type. These behave like Pascal pointers, in that they are rather safer, but far less flexible.

Micha Nelissen ha scritto:

You mean that declaring "twice" is smarter than declaring just once? You need two declarations: one for the type of the typed pointer, and one for the typed pointer itself. The Pascal type is visible in the pointer type declaration, and not in the pointer declaration (which is in a different section, var vs. type, which in a large program can be quite far away).
I hardly see the point.

You mean that string or object references where pointers are implicitly dereferenced make the code less readable?
A MyString^[3] or a MyButton^.Click would be more readable than the current MyString[3] and MyButton.Click?
It would be more consistent with the rest of the language, but what I suggest is to push consistency on the opposite direction.

You're actively trying to deceive me here? Nothing is declared "twice" as in "two times", but the declaration is split in two pieces. Btw, 9 times out of 10 the type declaration is reused multiple times so in the end it saves typing.

one for the typed pointer itself. The Pascal type is visible in the pointer type declaration, and not in the pointer declaration (which is in a different section, var vs. type, which in a large program can be

That's why names were invented in programming languages. Names can add meaning to types. It can make the reader see structure instead of chaos.

It would be more consistent with the rest of the language, but what I suggest is to push consistency on the opposite direction.

The opposite direction is the wrong direction.

Micha

Micha Nelissen ha scritto:

I try to make myself more clear. Of course the "based" construct comes useful when you're dealing with structured data such as records. And of course you need a type declaration for your record. But currently you need a second type declaration for a pointer to that record. This is not a split declaration, but an extra declaration.

The record type name is meaningful, the pointer type name is not. The usual way is to use the same name of the record, prepended by a P. If it can be inferred from the structure name, it's pleonastic. If it can't it's obfuscating. The "based" construct makes it implicit.

I've never found the C++ way (Button->Click) more telling than FPC way (Button.Click), on the contrary I find it cumbersome, but of course you're free to think otherwise.

Huh? Button.Click is perfectly legal in C++... Although it does not mean a dereference, but a direct ;) AFAIK the scandinavian mafia (Bjarne and Anders) did not agree, but both had the same in mind. Since Pascal already used ^ for pointers (pascal is much older than c++) Anders was free to use the simple dot notation to distinguish. Bjarne had to circumvent his reliance on C notation, hence the ->. I don't see the point about your argumentation. "Absolute" is supported, even explicit as opposed to implicit and that is a good thing.

Thaddy ha scritto:

Not if Button is a pointer. C++ makes a difference wether between Button.Click (direct) and Button->Click (dereference). FPC, in case of objects does not.