The Dink Network

By the way, here's some more info from the DinkC reference:

#my_proc() [user-defined function reference]
# Category: Basic Syntax
# Example:
# my_proc();

This is how you run a procedure located in the current script. [It's the
primary way, anyway -- set_callback_random() is another way.]

[WARNING: It is difficult to create meaningful user-defined procedures in
DinkC:
(1) values cannot be passed to user-defined procedures;
(2) as noted in "return", user-defined procedures cannot return values;
and
(3) to a procedure invoked this way, local, "int" variables in the rest
of the script are out of scope!

Consider this example key-## script:

void main( void )
{
int &myvar = 11;
my_proc( 22 );
}
void my_proc( int &passval )
{
say("my_proc: myvar=&myvar passval=&passval story=&story", 1);
}

Name this script, say, key-45.c and press the Insert key. Dink will confirm
that my_proc() gets invoked, but that variables &myvar and &passval are
unknown. Only the value of the global variable &story is available to the
function. But if you get into the proc using a goto...

void main( void )
{
int &myvar = 11;
goto my_proc_label;
}
void my_proc( int &passval )
{
my_proc_label:
say("my_proc: myvar=&myvar passval=&passval story=&story", 1);
}

...&myvar remains in scope in this case. But then again, there is no need
for the extra function header when goto is used.

To be sure, a user-defined procedure may create and use its *own* "int"
variables, but their values are not available to the calling procedure.
For a procedure's own local variables and a subordinate procedure's local
variables to be out-of-scope to each other is certainly in keeping with
the philosophy of procedural languages, like DinkC tries to be. But the
lack of any means except global variables for DinkC procedures to
communicate with each other makes this a serious design limitation.

Additional information: this design limitation is shared by external(). A
script could use external() to run another proc within itself; unfortunately,
external() temporarily creates a new instance of the script it calls, and
that instance's variables are not shared with this instance. It is worth
noting that run_script_by_number() does not create a new instance of the
script. This fact may hold the key to overcoming this or other limitations.]

See also:
external(), spawn(), run_script_by_number
[to invoke functions in other scripts]
goto, set_callback_random() [for other ways to invoke code in this script]
return [for related information]