[fpc-devel] Variable can not be initialized by named constant
Alexander Klenin
klenin at gmail.com
Sun Mar 1 20:05:14 CET 2009
On Mon, Mar 2, 2009 at 03:16, Daniƫl Mantione
<daniel.mantione at freepascal.org> wrote:
> Making typed constants writeable has been a disputed feature of the Borland
> dialect, I agree with that, but fact of the matter is they are writeable and
> thus cannot form a constant expression. The fact that there exists a $J
> directive does not change this.
Well, I'd say a better way that, in Delphi, there exists an unfortunately
designed obscure option to make them writeable.
I think that that option default is even more unfortunate -- Pascal language
was always distinguished for its clarity and clean design,
and 'writeable constants' is neither clear nor clean, IMO.
> There are some estethic arguments against this: allowing them into
> initalization results in a break of the separation between declarations and
> code Pascal has: The declaration suddenly gets an assignment statement
> built-in.
> I forsee also practical problems: Procedure initialization code would become
> much more complex. Rather than storing a fixed value in a variable one would
> need to take care of dynamic types, like ansistring management.
First, allowing to write to a constant is much more aesthetically
unpleasant to me.
Actually, Free Pascal is the almost the only language I know
(besides assembler and FORTRAN IV) allowing such break-of-contract by default,
without the need of any casts or pointers.
Second, I do NOT suggest to convert declaration into an assignment.
As you correctly noted, it is debatable whether such a feature is good or
bad for the language.
Although I personally think that benefits outweigh the costs, this is
totally separate topic.
What I suggest is to:
1) Disallow changing of constants, making them worth their name
2) Allow using of typed constants at the same places as untyped ones,
including initializer expressions.
This should not affect code generation at all, just parsing an constant folding.
--
Alexander S. Klenin
More information about the fpc-devel
mailing list