[fpc-devel] Some compiler changes...

[Michael Van Canneyt]

On Tue, 23 Jan 2007, Thorsten Engler wrote:

> While playing around with the compiler source to familiarize myself I've
> produced the attached patch. While I didn't set out to produce anything for
> inclusion into the official codebase at least some of the changes might be
> generally useful.
> 
> a) now modeswitch: m_ident_escape
> 
> Allows escaping of identifiers which might otherwise be recognized as
> keywords. This mirrors Delphi's (and Chrome's) implementation.
> 
> type
>   TMyRecord = record
>     &unit: Integer;
>   end;
> 
> No space is allowed betweehn & and identifier. As identifiers are not
> allowed to start with digits there is no collision with the &123 support for
> base 8 integer constants. 

I think this goes against all that pascal stands for. We don't want to
butcher the language. Next thing you'll be asking to have it case sensitive.
As a programmer you know that certain keywords are keywords. Don't use them
in your fields/variables whatever. Keep you code readable.

> 
> b) new modeswitch: m_always_ident_after_dot
> 
> There are no valid cases in the pascal grammer where a keyword follows a
> single dot. As a) makes it now possible to declare identifiers which are
> identical to keywords qualified access to these fields can now be simplified
> by always recognizing an identifier/keyword following a dot as a simple
> identifier, no matter if it matches a keyword or not.
> 
> I'm not sure if Delphi implements this. Chrome does.
> 
> var
>   myRecord: TMyRecord;
> begin
>   myRecord.unit := 123;
> end;
> 
> 
> These 2 switches should not affect compatibility to existing code. I can run
> a complete make all / make install with both of these generally active. It
> could be considered to add them to {$mode objfpc}
> 
> c) new $mode: m_chrome

If a is not implemented, then B should not be implemented either.

> 
> Currently baseed on objfpc with the addition of all 3 new mode switches. In
> addition to a) and b) m_chrome allows the use of "method" as an alternative
> to both procedure and function (if the method is a procedure or function can
> simply be determined by the presence of a defined result type).

No. It obfuscates the difference between procedure and function.
This is not C, but pascal.

Michael.