Op Mon, 2 Mar 2009, schreef Alexander Klenin:
On Mon, Mar 2, 2009 at 03:16, Daniël Mantione
<[email protected]> 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
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
