By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

V12 suggestions

Most of what's below I suggested previously, but renew it for V12.

1/ When using the INIKEY version, the registry should not be modified by
TCMD or TCC. Any information needed to be saved should be stored a/ in a
list functionally similar to the global lists, kept alive while the user is
logged in via a SHRALIAS clone (not by SHRALIS itself to retain user control
of SHRALIAS), or b/ in a file on the device whence TCMD or TCC is loaded,
specifiable either in the command starting TCMD/TCC or in the .INI file.

2/ Each top level instance of TCC should create a list of variables
modifiable from its own child instances of TCC. "Top level" here means that
exiting TCC (and its parents) would not return to another TCC instance. A
new variable function could be created to retrieve the value of a variable
from the top level list instead of a local environment variable of the same
name. Modifying the top level list would require a new option for the SET

3/ A shared global list of variables with similar features to the top level
variables list above, but shared by all instances in the manner of global
aliases, retained by SHRALIAS.EXE when no TCC instance exists. Would require
new option in SET to access. Hierarchy of variable retrieval for identical
names, using the simple % convention, would be first one found: GOSUB
parameter variables, environment (local) variables, top level variables,
global variables. This order is essentially the same as that used by the
C/C++ languages for nested code blocks - the innermost definition is used.

4/ Concurrent local and global aliases and functions. If a given name exists
in both the local and global list, normal usage would access the local one.
New functions could be added to be able to override the retrieval order. The
/G and /L options of the ALIAS and FUNCTION commands would cause accessing
the specified list . The commands with neither option would access the
default (global or local) list as selected when the current TCC instance was

5/ SETLOCAL should be truly local, i.e., even in a TCC instance using global
aliases, SETLOCAL should copy the global lists into local lists, and any
commands between SETLOCAL and the corresponding ENDLOCAL (explicit or
implicit) would access these local lists, unless an explicit /G option is
used. If the local list already existed, identically named global list
entries would be dropped, or placed in the list in a position where standard
search would find the local entry first.

Similar threads