© Tyl Software Foundation 2019-2021
▶ PROCESS MODULE
Working with Instance Process Modules
An instance module initialization and operation:
resetproc process 'state.reset.exe'
resetproc.execute
resetproc
was declared an instance
of process
module, and will have a relative path 'state.reset.exe'.
Once initialized
resetproc
variable can be used according to its scope, and
in line resetproc.execute
, resetproc
will be executed.
Suppose we have a state application 'state.app.tyl', that uses these processes:

! state.reset.exe
io.write 'app.state' 0
! state.get.exe
out io.read 'app.state'
! state.inc.exe
num number.of io.read 'app.state'
io.write 'app.state' num ++
out num
! state.set.exe
in0 number.of in 0
io.write 'app.state' in0
rp process 'state.reset.exe'
gp process 'state.get.exe'
sp process 'state.set.exe'
incp process 'state.inc.exe'
go »
rp.run
printstate
incp.run
printstate
setstate 10
printstate
printstate » print number.of gp.run
setstate num »
sp process sp.path num
sp.run
0
1
10
1
10
In the first lines, instance variables were declared for the
processes, then they were used to
run
their process. In
statement print number.of gp.run
, number.of
got the result of gp.run
result, and in line sp process sp.path num
, sp
was reinitialized
with sp.path
variable and the scalar argument num
. This was done
exceptionally because of the dual type of arg
, that prevents direct setting
of its value.
path
variable can be set also after module initialization:
rp process 'state.reset.exe'
gp process 'state.get.exe'
sp process 'state.set.exe'
incp process 'state.inc.exe'
go »
rp.run
printstate
rp.path incp.path
rp.run
printstate
printstate » print number.of gp.run
setstate num »
sp process sp.path num
sp.run
0
1
1
In line
rp.path incp.path
, the path of rp
got the path of incp
, and when
it was run
again, its process path was 'state.inc.exe', and it incremented the
state.