Tasks

System stack

Libraries use callbacks, so the system stack should not be used for petway tasks.

Tasks start with a tiny stack, 64 bytes?

Actual task code is Forth-alike threaded code.

Scoped variables

Program flow operators

Program structure: pointers to functions. Instead of bytecode and VM PetLang generates C code. A function in PetLang at C level is just an array of pointers to functions.

Functions all have same prototype, they take task as the argument. How about calling interface methods and C functions? - wrap these calls, do not use system stack. Function has a scope and optionally nested scopes. Scopes are structs, they are typed. PetLang programs use task stack. The system stack is used only for native C calls. A C function cannot directly call PetLang function. It can only schedule its execution upon return in the context of a new task.

This demands tasks to be lightweight as much as possible, with fast creation.

What to do after task complete?

Scenario 1: a C function wants to run a PetLang function and get its result.

Scenario 2: a callback needs to schedule a task and return immediately (?) But what if callback gets a buffer which the caller would overwrite each time it calls the callback? The callback either must process the data immediately or copy it. As long as PetLang program does not use system stack, it may continue in the callback. Alternatively, the callback may run "data-provider" code for unwrapping state-machine style. Actually, this means runing in the context of the task for which we provide the data.

Because pet programs do not use system stack, we cannot have a function like run_pet_program because when a pet program calls a pet function there should not be any real calls -- bullshit, run_pet_program can only calls func pointers of pet program.

Again, pet program is a sequence of pointers.

Program flow can use special "unaligned" pointers; on 32-bit architecture pointer should be aligned on 4-byte boundary so we have two available bits which give us three options (the fourth is normal pointer when both bits are zero):

1: jump 2: call 3: return

All options are conditional, they take place only when if task->condition is true

Interfaces

PetWay interface methods are synchronous and cannot call pet programs.
For pet programs there should be something different

A function in a pet program can be a single block of C code if it neither yields nor calls another pet function. Otherwise it breaks into two or more functions.