the consequence of this is that global variables are only visible in
included scripts if they require the "include" extension themselves. I
don't think this natural behaviour, and why I have advocated making
variables global by default.
there is an alternative which may be easier to get consensus for: the
change of text above, and an extra extension, call it "globals".
"globals" adds the :global modifier for "set" _and_ makes already
declared globals available to the current script.
... where a global variable is available both to the current script, to all
scripts it includes, and all scripts that include it.
Either of the above would be fine by me, and I agree the latter would be
preferable :o)
I consider the contents of a .siv file to be a script. And that you can build
larger scripts by using the include extension. To declare that "there is only
one script" seems quite confusing to me, as what then do you call a .siv file
that is included by the parent siv file? Is it not a script too?
Conveniently, the abstract of the include spec already seems to already fit
with my definition of a script.
this means that a script will only be able to use the variables it has
set itself unless it explicitly asks to import the globals.
.. and it uses the :global modifier when it uses the set action.
"globals" can be put in the "include"-document, or in a separate
document. I favour the former as I think there is a natural connection.
(it could also be in "variables", but that would delay the document
needlessly.)
I agree, and again I think it preferable to change the word "global" to "file"
in the variables draft in order to avoid confusion generated when reading
include+variables. I would settle for what Aaron just suggested, but it still
means we end up with two meanings for the word "global".
Nigel