Today I found this type definition in some FreePascal sources:

TypeReal =type Double;

I wondered what the second “type” keyword means here (I have never seen this before).

So I looked at http://www.freepascal.org/docs-html/ref/refch3.html#refse17.html

where it says:

_________________________________________________________________________________________________________ Type declaration

-- - - - -|-------------- --------------- type declaration identifier = type |- --|; hint directives ___________________________________________________________________

Although type declarations are very fundamental and I am using them since 30 years I can’t find out what this diagram is trying to tell me.

For example, I am missing the keyword “TYPE” in this syntax diagramm.

I don’t know whether the first “type” is the standard type definition entry keyword but if so it should be typed in bold font.

It can also be part of a text “type declaration” (which is obviously not a keyword).

But then why does “type declaration” appear twice (in the heading **and** the syntax diagramm)? Following the line should generate a valid path to a (syntactical) correct type declaration. But why is then "type declaration" part of a type declaration? Makes no sense to me.
It would generate an endless recursive loop.

Another problem is “hint directives”.

What is it? There is no link nor text that explains it.

So I started another google search for “hint directives”

but I only found this: http://www.freepascal.org/docs-html/ref/refse5.html <http://www.freepascal.org/docs-html/ref/refse5.html>

where it says that hint directives are for variable declarations but not for type declarations (and again "hint directives" are part of hint directives which is not correct IMO).

Can someone clarify this documentation please?

Where can I find the documentation for my original question about the double TYPE keyword?

You are being rather obtuse.
Ignore the diagrams in the docs if they don't help you.

The double use of type here simply means that the "Real" type is being defined as an alias for double. The two type identifiers now mean exactly the same thing as the "=" indicates.

The documentation for hint directives gives three clear and explicit examples of different hint directives showing how to declare them and the compiler-generated hints that result from their use.

What more do you want?

Howard

No, an alias would be

=== code begin ===

type
   Real = Double;

=== code end ===

Using the "type" behind the "=" tells the compiler to declare a new type based on the right side. So a "Double" and a "Real" are not assignment compatible and can have different sets of operator overloads.

Regards,
Sven

You are right. That seems to be missing.

I don’t know whether the first “type” is the standard type definition entry keyword but if so it should be typed in bold font.

No, it's not the keyword, it's a "reference" to the syntax diagram named "type" directly below it (though I have to admit that this is not necessarily clear...).

Yes, this is indeed the correct documentation and maybe this should be linked better...

(and again "hint directives" are part of hint directives which is not correct IMO).

The "hint directives" is again the "name" of the syntax diagram.

This link explains it a bit:
http://docwiki.embarcadero.com/RADStudio/XE5/en/Type_Compatibility_and_Identity

Regards,
Sven

Thanks for the clarification. That is a distinction worth drawing attention to in the documentation, and its relevance when writing overloaded routines.
Looks like the obtuseness is at this end, as well as at Jürgen's.

Howard

That is right, since it is not the diagram for the type declaration block, which appears later in the manual.

However, following your remark I have done some reworking of this part. I have referred to the diagram of the type declaration block, and I have moved the type alias description to a separate section which explains the difference between the 2 concepts:

Type
   MyInteger = Integer;
and
   MyInteger = Type Integer;

You can preview the result at

http://www.freepascal.org/~michael/ref/refch3.html

Michael.

That is not quite correct.

They ARE assignment compatible, but can indeed have different sets of overloads.

As in the following example:

home: >./ta
Different types
home: >cat ta.pp

Type
   TA = Integer;
   TB = Type TA;
Var
   A : TA;
   B : TB;
begin
   B:=1;
   A:=B;
   if TypeInfo(TA)TypeInfo(TB) then
     Writeln('Different types');
end.

Michael.

type based on the right side.

So a "Double" and a "Real" are not assignment compatible and can have

different sets of operator overloads.

Thanks for the answer.
I already suspected such a definition.

But why is it not part of the documentation?
If nobody takes care of the documentation anymore
then it should better be the current documentation is very bad and outdated. Not very inviting for potentially interested programmers. Without a reliable documentation all programming is just guessing and hoping and trial and error.

The SVN logs will convince you that it is updated on a regular basis.

I usually respond positively to all requests for updates, as my other reply proves.

That is, provided they are put in a positive form, and not with a dosis of poison as you just provided.

If you insist on being negative, please find another mailing list to do so.

Michael.

"Jürgen Hestermann" wrote

But why is it not part of the documentation?

We are all just human beings that make mistakes. Nobody is perfect and so is the documentation.

If nobody takes care of the documentation anymore then it should better be 's actively maintained on Subversion... IMO the current documentation is very bad and outdated.

... but only "publicly" updated on each release.

Without a reliable documentation all programming is just guessing and hoping and trial and error.

Then please continue to point out inconsistencies and unclear parts so that the documentation can be improved. But please do so - as Michael suggested as well - without this "bah, there's a problem, so it's crap"-attitude. We are all working on this during our free time afterall...

Regards,
Sven

Is there any way to get support in Free Pascal for the old six byte REAL type that was provided by the old Borland DOS Turbo Pascal compilers? There was support for the six byte REAL in the old Virtual Pascal compiler, so I wondered if there is some obscure unit that can be enabled to turn on legacy support for it.

I do understand that a DOUBLE is larger than a six byte REAL, so support for the old type is only meaningful when reading a typed file of records that include this outdated data type. Some old code here uses the old type REAL extensively, even for large whole number values to avoid using the signed 32-bit integer type, LONGINT.

I know the documentation does not mention the six byte REAL type. I wondered if there is any support for it.

Is there any way to get support in Free Pascal for the old six byte REAL type that was provided by the old Borland DOS Turbo Pascal compilers?

The only support we have is a routine to convert a TP-style real to double: http://www.freepascal.org/docs-html/rtl/system/real2double.html

Jonas

Sven Barth wrote

> I don’t know whether the first 'type' is the standard type definition > entry keyword but if so it should be typed in bold font. No, it's not the keyword, it's a "reference" to the syntax diagram named "type" directly below it (though I have to admit that this is not necessarily clear...).

It seems that all syntax diagrams have the same issue:

That what should be declared is repeated in the declaration itself which makes no sense to me.
A syntax diagram for 'type declaration' (which is written in the heading already) cannot have the text 'type declaration' again in the diagram. The diagram just should explain 'type declaration'. Following the line should reveal a syntactical correct 'type declaration' so it should not contain itself the text 'type declaration'. Otherwise it recursively explains itself in an endless loop.

> Where can I find the documentation for my original question about the double TYPE keyword? This link explains it a bit: http://docwiki.embarcadero.com/RADStudio/XE5/en/Type_Compatibility_and_Identity

But that's not part of the Free Pascal documentation. So it's not available in the documentation of Free Pascal? Who can know when he has to look at the Delphi
documentation (which version?) and when this differs from Free Pascal?

Didn't I just write that it is indeed still missing?! (though Michael seems to have fixed it in the SVN sources, so this fix will (maybe?) be part of the 2.6.4 documentation)

Who can know when he has to look at the Delphi documentation (which version?) and when this differs from Free Pascal?

You shouldn't need to look at the Delphi documentation. It's just that I wanted to answer your question with a source. If I the feature would have been available in TP and the syntax would be available I would have linked that. Or the ISO specification or whatever. This has nothing to do with "this is found in FPC's documentation so you need to look somewhere else", but I simply digged out a link were this feature is described.

And to come back to the first sentence of the paragraph: and this is where you come into play: by raising such questions you can help improve the documentation.

Regards,
Sven

The heading is a caption.

In typesetting, normally that is not considered part of the diagram itself, just like a table or figure caption is not considered part of the table or figure.

As Sven surmised, it will be in the next version.
I posted a preview for your benefit, please see my initial answer.

Michael.

Michael Van Canneyt wrote

You can preview the result at http://www.freepascal.org/~michael/ref/refch3.html

You might additionally mention that these type aliases also allow different operator and (AFAIK also) function overloads.

Regards,
Sven

Will do, thanks.

Michael.

But why is the heading part of the diagram?
It should be just that: A heading (in an extra line before the diagram). For example on page 29:

String Type
----- string type -- STRING --|--------------------------------|---- \-- [ -- unsigned integer -- ] --/

There is already the heading "String Type",
then - as part of the diagram (surrounded by lines) - "string type" appears again! Why?
That's totally confusing.
It should be like this:

String Type:
----- STRING ----|--------------------------------|---- \-- [ -- unsigned integer -- ] --/

or

String Type =
----- STRING ----|--------------------------------|---- \-- [ -- unsigned integer -- ] --/

Also, that they have different RTTI records, that is the TypeInfo() compiler function returns different pointers for the original and derived type, while for simple type aliases (no "type" after "=") it returns the same pointer.

In Delphi and I suppose in Lazarus this is often used in order to register a specific property editor for each property of an otherwise common type that has special semantics, e.g.

type
  TFileName = type string;

This is already mentioned in Michael's preview.

Regards,
Sven

Because that is how the typesetting mechanism for syntax diagrams work.

Michael.

I already mention all this.

Michael.

Michael Van Canneyt wrote

> But why is the heading part of the diagram? Because that is how the typesetting mechanism for syntax diagrams work.

That's not true (at least not in diagrams other than in Free Pascal). It is very illogical to begin a diagram with the name of what the diagramm should specify. The name has to be put *in front* of the diagram but not inside. That's like writing a procedure or function and the first command after the begin is a (recursively) call of the procedure itself. This would lead to an endless loop.

See page 61 where "object types" are declared with a correct diagramm. The diagram name ("object types") is on an extra line and the diagram itself (which starts with 2 arrows) begins on the next line. So when I start my run throught the diagram at the 2 arrows the first word I can get is "packed" (and not "object types").
The arrows/line starts *after* the name, not before. But already the next line is incorrect again because "heritage" is part of the diagram (the line/2 arrows start left of it but should not).

Look at http://en.wikipedia.org/wiki/Syntax_diagram and see the diagrams at the bottom. These are correct syntax diagrams.
The name ("expression:", "term:", "factor:", etc.) is on one line and the diagram (the line which here starts with a circle) begins on the next line. Name and diagram can also be on one line (though this makes it already less clear) but the name of the diagram should never appear after the 2 arrows (which start the path).

I meant that I use a diagram typesetting package for LaTeX. This package definitely works like that.

Michael.

Michael Van Canneyt wrote

I meant that I use a diagram typesetting package for LaTeX. This package definitely works like that.

Then something is wrong with this package.
Which one is it?

And as I wrote, there are diagrams which do *not*
repeat the header (diagram name) in the diagram:
On pages 69,85,98,103,110,114 and 115 each diagram starts with a (bold) keyword ("packed"/"class, "Interface", "extended record type", "class"/"record", "objcclass", "objcprotocol" and "objccategory")
and not with the diagram name.
This is what I would expect for all other diagrams too. Why this inconsistency?
If the diagrams stay like this they are too confusing to be of any use.

There are some other glitches I found while reading the documentation:

*) Page 158: A superfluous line exists.

*) Page 180: The diagram seems to imply that a finalization part cannot be added without an initialization part.

listings.sty

I didn't write this package, but I'm sure its author will appreciate your insights.

I don't necessarily consider this inconsistent.

If the diagrams stay like this they are too confusing to be of any use.

That is your opinion, to which you are of course entitled.

Feel free to make suggestions for improvements.
If I consider the suggestions good, I will certainly incorporate them.

But I kindly suggest you change your tone. You may not realize it, but your tone is edging on arrogant.

Michael.

In our previous episode, Michael Van Canneyt said:

syntax.sty?

Michael Van Canneyt wrote

> Why this inconsistency? I don't necessarily consider this inconsistent.

Why not?
Do you mean syntax diagrams don't need any logic?

> If the diagrams stay like this they are too confusing to be of any use. That is your opinion, to which you are of course entitled. Feel free to make suggestions for improvements. If I consider the

suggestions good, I will certainly incorporate them.

How kind you are...
Now if that is not arrogant...

You seem to imply that I am demanding something for myself. But I only report these documentation problems for potential new users because I think that Pascal should be used by more people while you seem to not care about them.

But I kindly suggest you change your tone. You may not realize it,

but your tone is edging on arrogant.

That's your opinion.
I find it arrogant to deny logic errors in syntax diagrams.

In their headers ? No. In the content ? Yes.

That is not arrogant. I am the author of the documentation. So it is entirely my decision what goes in it and what not. So I'm just stating a fact.

Well, you seem to think that you represent 'all users' which is 'arrogant' imho.

I think we just differ in opinion on what consitutes a good diagram. So, it is my opinion against yours.

Your problem with the captions of the diagram I do not consider to be a general problem of the diagrams, but I think it is more you personally who cannot accept the form of the diagrams. Hence, I will not change that aspect.

But as I said: if I agree with one of your opinions, I will certainly take it to heart.

What is more: I have already done so. As a result of your remarks I have changed the type diagram, and I added a section on type aliases.

That is all there is to say about it.

Michael.

Sorry, yes. listings.sty is for the code fragments.

Michael.