[fpc-devel] Variable can not be initialized by named constant

[Daniël Mantione]

Op Mon, 2 Mar 2009, schreef Alexander Klenin:

> 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.

This is a debate that has been held quite a few times :) If you look at 
typed consts from the point of view what a mathematical constant is, yes, 
it's completely absurd that you can write to them.

But... you need to look at typed consts what they do, and not how they are 
named. If you look at the language feature typed consts from you will see 
that they are not mathematical constants that exists only at compile time. 
If you want a real constant that just has a type you can do something like 
"const x=longint(1)". In contrast with constants, typed consts describes 
actual data that will appear in memory.

The compiler cannot prevent you writing to data in memory, since at 
runtime, the coder is the boss. All you need is to cast them into a 
pointer. Works flawlessly, regardless of the $J state. From this point of 
view of the function typed consts form, allowing writes to them isn't that 
illogical.

> 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.

Remember again that:

const x:longint=1;    {Defines a location in memory large enough to
                        hold an integer, which contains value 1.}
       y=longint(1);   {Defines a compile-time symbol that is equavalent to
                        writing longint(1) somewhere in the code.}

... do completely different things inside the compiler.

It will affect code generation, since typed consts are stored in memory. 
There exists no constant folding for typed consts, because they need to be 
layed out in memory exactly as the programmer describes, the compiler 
cannot mess with that unlike with real compile-time constants. Basically 
code has to be generated that reads the typed consts from their fixed 
position in memory and copied into the variable.

Of course disallowing writing to typed consts is problematic because of 
people making use of this functionality. After all, typed consts existed 
long before initialized variables were invented and I'm sure people are 
still using them.

Daniël