[fpc-devel] Some compiler changes...
thorsten.engler at gmx.net
Tue Jan 23 10:01:42 CET 2007
-----BEGIN PGP SIGNED MESSAGE-----
> What could be a rood reason to escape a keyword? Why do you
> as programmer insist on the use of a keyword? Why do you
> insist that your property is called 'unit'? It's just
> obfuscating the code. With this you can mangle your code completely...
Delphi (and Chrome) introduced this escaping mechanism because they had to
survive in an environment where they needed to consume and extend types
which have been defined in another language with a different set of reserved
keywords. It is NOT intended for you to go wild and start naming everything
with funny names. The example given was purely my test project to see if it
works. Not intended as an example of what you should do.
With FPC supporting different modes and keywords being dependant on mode you
are in exactly the same boat as Delphi and Chrome. You might need to access
symbols that for you (under the current mode) are a keyword but under the
mode where they were declared are just an identifier.
As Delphi _does_ support this mechanism, if you are interested in keeping
compatibility to Delphi you'll have to at least allow this mechanism in
Just to say it again. This is not a mechanism that should be used for
anything but compatibility. If you want to enforce the limitation of the use
to compatibility only it's possible to introduce additional checks in the
parsing stage (as opposed to the tokenizer where this is currently
implemented) that prohibits the use of this mechanism in any cases not
related to using or extending an already existing type (meaning that e.g.
for declaring methods it is only acceptable if the method is used to
implement an interface or to override a virtual method that already has this
name). That way you could prevent people from abusing this functionality.
> And about the 'method' thing... We could also replace the 'property'
> keyword by 'something'. Hey, we can also replace method by
> Woudn't that be nice. So you get:
> TMyObject = class
> Fs : String;
> something Foo;
> something Bar: Integer;
> class something ClassFoo;
> class something ClassBar: Integer;
> something s : read Fs write Fs;
> Hmm... maye it's better to get rid off 'something' completely, then...
> In short: why do ou want to get rid of the difference between
> 'procedure' and 'function'?
> Or do I miss something completely?
Yes, replacing property with the same keyword creates ambiguities that would
require multi token lookahead to resolve. Combining function and procedure
into the same keyword does not introduce any ambiguity. You might have
noticed that both are represented by the same tprocdef. Their code is
generated in the same way and they are called in the same way. From a
grammar standpoint "function" and "procedure" are really just noise words.
The grammar inside these 2 productions is identical except for one requiring
and the other prohibiting a specific sub production. The distinction between
procedure and function is an artificial one, take the production for
function, make the resulttype optional and you have merged the 2 without
creating any ambiguity. Property and methods on the other hand have totally
different productions, are represented by different defs, are used in
different ways. Using the same keyword for that would be lunacy. ;)
I also want to point out that I'm in no way proposing of adding this to any
of the existing modes. I've added it to a new mode Chrome. As for "why do
you want to get rid of...", for the same reason you do anything that you do
in $mode delphi. Because THEY already did it. (Just in case anyone doesn't
know what Chrome is and thinks I'm inventing a new language myself here:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
-----END PGP SIGNATURE-----
More information about the fpc-devel