First i will note that what i state is not an error or bug in free pascal, but it is somehow unclean implemented.
The decision for modifiers like cvar or cdecl to be an <identifier> token or an <modifier> token relies on context information. But what is that context? An example:

type
  name=procedure;
  cdecl=integer;

results in an error, but

type
  cdecl=integer;
  name=procedure;

is correct.

The procedure type declaration consumes the <cdecl> token regardless of the following token.
There is no need for this. The <=> token can be used as context switch, but you´ll need a look ahead of 2 tokens. And that conflicts with the LL1 base structure of pascal. What a pity.

For some other modifiers you have the same situation

var
  name:typ;
  cvar:integer;

is an error, but

var
  cvar:integer;
  name:typ;

is correct.
You may say in most circumstances the required <;> token right before the modifier token is the problem.

For example for the <absolute> directive this kind of problem does not arise.

The forward directive is another example, would´nt it be better to have forward be an keyword?

I think if the compiler allows one construct he should not reject the other. But, i am not the first programmer who complains about that, so put it in the garbage. (Or start discussion)

Sorry for my bad English,
with best regards

Jörg Schülke

In our previous episode, Joerg Schuelke said:
[ Charset UTF-8 unsupported, converting... ]

    =integer;

The compiler looks for modifier in certain spaces, like after a procedure declaraction. IOW the compiler reads it like above.

No, since modifiers can be in any order, it could be a lot more than two tokens.

Am Thu, 28 Apr 2011 18:22:38 +0200 (CEST)
schrieb (Marco van de Voort):

I think if the compiler reeds the <cdecl> token he needs a lookup of only one token to decide: is used as a <modifier> or a <identifier> token.
Jörg

First i will note that what i state is not an error or bug in free pascal, but it is somehow unclean implemented.

The bug resides in the dirty Delphi OPL definition.

DoDi

Am Thu, 28 Apr 2011 23:39:35 +0200
schrieb Hans-Peter Diettrich :

The bug resides in the dirty Delphi OPL definition.

Is it a bug or unspecified behavior? I think it is implemented in the hope it works good enough.

If you consume a <modifier> token as <modifier> or <identifier> in respect of the right context of one token, you get rid of this strange behavior and you will get a real superset of the former language.

So, why not doing it?

Jörg

In our previous episode, Joerg Schuelke said:

No, since if the next token is "deprecated" he has the same devilish tradeoff.

Not that I am advertising to change it, but the next token wouldn't be deprecated ever (that would be a syntax error (afaik), there has to be a ";" first).

Leaving out comment and compiler directives, the next token can be: ,;:=
// ";" not an idetifier
var a: procedure; cdecl;
// ,:= identifier
var a: procedure; cdecl, b: byte;
var a: procedure; cdecl: byte;
type: a=procedure; cdecl=byte;
// ' not an identifier
var a: integer; deprecated 'please do not use';

There are already 2 word tokens like
strict private

So cdecl and all the others could work as 2 "word" tokens too. cdecl simply is a prefix to the next token, then if a "," or ":" is read, an "cdecl" identifier is inserted and the ", or ":" handled; if a ";" is read the cdecl is handled as part of the procedure before.

Martin

In our previous episode, Martin said:

True, by bad. Indeed you could select on : vs ;

The FPC scanner is simply not designed for a look ahead > 1. Especially macro and include file expansion as well as generics require probably a major rewrite of the scanner.