Klaas-Jan Stol wrote:
2.b is the ".constant" directive from pasm mode (which is in the macro
layer) removed?
After some discussion on IRC and review: the only thing I want to change
from the current way constants work is to change the name of the
'.constant' macro substitution to '.macroconst', and allow '.macroconst'
to be used from within PIR.
Macro constants can't be type checked, stored in bytecode, or
introspected, and so are discouraged for user code. But they are a
lightweight way to provide PIR access to C constants (they simply
disappear during compilation). There are currently several sets of PASM
macro constants being generated from the C constants or for specific
subsystems, notably runtime/parrot/include/*.pasm.
>> 2.a line 246, about .globalconstant, doesn't specify when the global
>> is initialized. Is that when the sub in which it is declared is
>> executed/compiled/loaded? Or at startup?
Both '.const' and '.globalconst' are initialized during compilation.
There's an inconsistency currently in that .const is allowed both inside
and outside compilation units, while .globalconst is only allowed inside
compilation units. The only difference between the two should be that
.const stores the constant in the current bytecode file (in the constant
table, the same place unnamed constants get stored), while .globalconst
stores the constant in a global constant table.
In general, the use of '.const' is preferred over '.globalconst', to
diminish effects on other libraries/classes/HLLs running in the same
interpreter at the same time.
Allison
