Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2011-04

type pointer to record before record.

7 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Skybuck Flying

Hello,

In free pascal/pascal/delphi it's necessary to declare a pointer to a record, which is to be used inside the record to point to itself, before the record itself without a type directive in between them for example:

// correct:
type
    PMyRecord = ^TMyRecord;
    TMyRecord = record
        mSelf : PMyRecord;
        mNext : PMyRecord;
    end;
// incorrect/not allowed:
type
    PMyRecord = ^TMyRecord; // above type anywhere else.
type
    TMyRecord = record
        mSelf : PMyRecord;
        mNext : PMyRecord;
        mPrev : ^TMyRecord; // not allowed.
    end;
    PMyRecord = ^TMyRecord; // below anywhere else
// and so forth...

I would first like to remark about this: "This is very newb unfriendly... newbs might not know this... and will get frustrated by this weird/odd/non-intuitive language construction".

Now some question about this:

1. Is there a compiler-related technical reason why it has to be like this ? If so explain shortly...

2. Is there perhaps a technical solution for it so this is no longer required ? If so how much effort would a solution cost ?

3. (Does free pascal still follow these restrictions ? I guess so... )

Final question assuming it's solvable::

4. Do you think it's worth to solve this oddity and make the language more newb friendly and more intuitive ?

5. Would it break anything ? (I think not... it would be an extension/relaxation of the language...)

Bye,
Skybuck.

Reply by email

Marco van de Voort
to Skybuck Flying

In our previous episode, Skybuck Flying said:

I would first like to remark about this: "This is very newb unfriendly... newbs might not know this... and will get frustrated by this weird/odd/non-intuitive language construction".

It's in all manuals and books that describe pascal pointers that I know off.

Now some question about this: 1. Is there a compiler-related technical reason why it has to be like this ? If so explain shortly...

Yes, as soon as a type block closes (when whatever next block starts), the compiler knows that the types in the block must be completely defined. If not he must deal with the possible incomplete state of identifiers throughout the whole compiler, now only in the typeblock.

2. Is there perhaps a technical solution for it so this is no longer required ? If so how much effort would a solution cost ?

It's like Joerg remarks about the modifiers. Things can be done, but lead to much larger problems to solve elsewhere. It is not worth it.

That being said, the example is a more easily solved case. Since that is a sequence of typeblocks rather than a alternation of different kind of blocks.

Trouble is that after 42 years of pascal, cases like this can have been done deliberate. IOW to limit forward looking and get errors earlier.

Changing this and partitioning the Pascal dialects in the ones that have it, and the ones that have not (and most will have not) is idiotic.

3. (Does free pascal still follow these restrictions ? I guess so... )

Yes

Final question assuming it's solvable:: 4. Do you think it's worth to solve this oddity and make the language more newb friendly and more intuitive ?

No. Not even the trivial repeated "TYPE" case.

Such changes create more confusion that they solve.

5. Would it break anything ? (I think not... it would be an extension/relaxation of the language...)

The repeated sequence of TYPE not that much, but people would rely on it, and it might confuse people using multiple compiler and dialects (errors suddenly happen on different moments)

As soon as you start with also allowing other blocks, then it becomes a massive problem.

Reply by email

Skybuck Flying
to Marco van de Voort

----- Original Message -----

Earlier message 142 lines
From: "Marco van de Voort" To: "FPC developers' list" Sent: Friday, 29 April, 2011 10:35 AM Subject: Re: [fpc-devel] type pointer to record before record. > In our previous episode, Skybuck Flying said: >> I would first like to remark about this: "This is very newb unfriendly... >> newbs might not know this... and will get frustrated by this >> weird/odd/non-intuitive language construction". > > It's in all manuals and books that describe pascal pointers that I know > off. A 13 or 15 year old kid that wants to learn pascal might not be able to afford such books. > >> Now some question about this: >> >> 1. Is there a compiler-related technical reason why it has to be like >> this ? >> If so explain shortly... > > Yes, as soon as a type block closes (when whatever next block starts), > the > compiler knows that the types in the block must be completely defined. If > not he must deal with the possible incomplete state of identifiers > throughout the whole compiler, now only in the typeblock. This seems little to nothing new compared to forward declarations, and perhaps call sites which call not yet linked in functions and/or perhaps while loops which do not yet know the end of the loop or repeat until statements. > >> 2. Is there perhaps a technical solution for it so this is no longer >> required ? If so how much effort would a solution cost ? > > It's like Joerg remarks about the modifiers. Things can be done, but lead > to > much larger problems to solve elsewhere. It is not worth it. Give one example of such a problem ? ;) > That being said, the example is a more easily solved case. Since that is a > sequence of typeblocks rather than a alternation of different kind of > blocks. These type of problems are not easily solved by noobs who don't know this very peculiar thing. > Trouble is that after 42 years of pascal, cases like this can have been > done > deliberate. IOW to limit forward looking and get errors earlier. Mhoaw weak argument really, these kinds of coding problems are very common when coding and programmers will get used to that. > Changing this and partitioning the Pascal dialects in the ones that have > it, > and the ones that have not (and most will have not) is idiotic. You might be surprised but free pascal is already different than Delphi in this regard, I came across one such example in the free pascal compiler code itself. I had to move certain records, and change certain orders, not a huge problem for an experienced Delphi programmer like me ;) (In case you interested in this difference, checkout my svn source tree where I attempted to port free pascal to Delphi, then search comments for "Skybuck" and perhaps "move" or something, somewhere in that source code/comments you'll find it). >> 3. (Does free pascal still follow these restrictions ? I guess so... ) > > Yes Not entirely I would think... somewhere there is a difference with Delphi. > >> Final question assuming it's solvable:: >> >> 4. Do you think it's worth to solve this oddity and make the language >> more >> newb friendly and more intuitive ? > > No. Not even the trivial repeated "TYPE" case. > > Such changes create more confusion that they solve. I don't think so, not with modern IDE's... if/when I want to know where a pointer type is declared I simply use "Find Declaration". How could that possibly be confusing, especially when we new to the language change/feature know what is happening. For a newb it probably doesn't matter for him it becomes more easy when using the new easified language ! ;) =D (And again frustrating when he tries to port it to the old language). > >> 5. Would it break anything ? (I think not... it would be an >> extension/relaxation of the language...) > > The repeated sequence of TYPE not that much, but people would rely on it, In what possible way would they rely on it ? This seems very strange to me ! ;) > and it might confuse people using multiple compiler and dialects (errors > suddenly happen on different moments) I don't think so, if they truely test their code on both compilers they will code for the compiler with the most restrictions, the new language feature does not present a problem for that. > As soon as you start with also allowing other blocks, then it becomes a > massive problem. Neh, I think you exaggerating it greatly ;) Unless it's allowed to declare these pointer types in other units which are used before the record is declared. Which in itself is kinda interesting anyway. And perhaps even when these pointers are used in all kinds of records before the record is declared. On the other hand this would allow some what more flexibility of data structures. In general I don't have problems with how the things currently work, but these type limitations seem very odd, I saw C/other language programmers who thought it was impossible to do this in pascal... For them it might have been a reason to choose C over Pascal. Bye, Skybuck.

Reply by email

Florian Klaempfl
to Flávio Etrusco
Flávio Etrusco wrote 8 lines
> type > TMyRecord = record > mPrev : ^TMyRecord; // not allowed. > end; Marco, only if you happen to know from the top of your head, would it be possible and without consequences to allow this kind of construction? (i.e. a pointer reference to itself)

No. Because TMyRecord could be already defined in another unit.

Reply by email

Skybuck Flying
to Florian Klaempfl

----- Original Message -----

Earlier message 39 lines
From: "Florian Klaempfl" To: "FPC developers' list" Sent: Friday, 29 April, 2011 15:57 PM Subject: Re: [fpc-devel] type pointer to record before record. > Am 29.04.2011 15:51, schrieb Flávio Etrusco: >>> type >>> TMyRecord = record >>> mPrev : ^TMyRecord; // not allowed. >>> end; >> >> Marco, only if you happen to know from the top of your head, would it >> be possible and without consequences to allow this kind of >> construction? (i.e. a pointer reference to itself) > > No. Because TMyRecord could be already defined in another unit. Unit1.TMyRecord Unit2.TMyRecord is allowed as long as both units do not reference each other. In case one of the two units reference each other there would probably be an error message that TMyRecord is already declared and that there is a conflict. Therefore this error situation that you fabricated is already caught by the compilers at least I know Delphi will. Perhaps you are referring to a problem inside the compiler in relation with the symbol table, in that case an easy fix would be to apply: Unit1.TMyRecord, Unit2.TMyRecord so place unit name in front of symbol, but this is probably already done since this is legal as long as they not referencing each other. Bye, Skybuck.

Reply by email

Alexander Klenin
to Florian Klaempfl: No. Because TMyRecord could be already defined in another unit.
Florian Klaempfl wrote 12 lines
Am 29.04.2011 15:51, schrieb Flávio Etrusco: >> >> type >>  TMyRecord = record >>      mPrev : ^TMyRecord; // not allowed. >>  end; > > Marco, only if you happen to know from the top of your head, would it > be possible and without consequences to allow this kind of > construction? (i.e. a pointer reference to itself) No. Because TMyRecord could be already defined in another unit.

Do you mean that ^TMyRecord could refer to a same-named type from the other unit?
It would be horrible -- but, fortunately, it is not so both in FPC and Delphi. So I think Flavio's point stands.

Alexander S. Klenin

Reply by email