From 88534f7472b8171304fc1da4ae0aef58c2a52708 Mon Sep 17 00:00:00 2001 From: David Thompson Date: Sat, 14 Oct 2017 21:42:15 -0400 Subject: scripting: Rename coroutine to script. * chickadee/scripting/coroutine.scm: Move to... * chickadee/scripting/script.scm: ...here, and s/coroutine/script. * chickadee/scripting/channel.scm (channel-get, channel-put): Update docstring to say "script" instead of "coroutine". * chickadee/scripting.scm: s/coroutine/script/ * Makefile.am (SOURCES): Replace coroutine.scm with script.scm. * doc/api.texi: s/coroutine/script/ --- doc/api.texi | 96 +++++++++++++++++++++++++++++------------------------------- 1 file changed, 47 insertions(+), 49 deletions(-) (limited to 'doc') diff --git a/doc/api.texi b/doc/api.texi index 32a797b..1f69059 100644 --- a/doc/api.texi +++ b/doc/api.texi @@ -1134,16 +1134,16 @@ enemy follow and attack the player, or move an NPC back and forth in front of the item shop, or do both at the same time, a scripting system is a necessity. Chickadee comes with an asynchronous programming system in the @code{(chickadee scripting)} module. -Lightweight, cooperative threads known as ``coroutines'' allow the +Lightweight, cooperative threads known as ``scripts'' allow the programmer to write asynchronous code as if it were synchronous, and allow many such ``threads'' to run concurrently. -But before we dig deeper into coroutines, let's discuss the simple act +But before we dig deeper into scripts, let's discuss the simple act of scheduling tasks. @menu * Agendas:: Scheduling tasks. -* Coroutines:: Cooperative multitasking. +* Scripts:: Cooperative multitasking. * Tweening:: Animations. * Channels:: Publish data to listeners. @end menu @@ -1252,22 +1252,22 @@ Schedule @var{body} to be evaluated every @var{interval} amount of time. Repeat this @var{n} times, or indefinitely if not specified. @end deffn -@node Coroutines -@subsection Coroutines +@node Scripts +@subsection Scripts Now that we can schedule tasks, let's take things to the next level. It sure would be great if we could make procedures that described a series of actions that happened over time, especially if we could do so without contorting our code into a nest of callback procedures. -This is where coroutines come in. With coroutines we can write code -in a linear way, in a manner that appears to be synchronous, but with -the ability to suspend periodically in order to let other coroutines -have a turn and prevent blocking the game loop. Building on top of -the scheduling that agendas provide, here is a coroutine that models a -child trying to get their mother's attention: +This is where scripts come in. With scripts we can write code in a +linear way, in a manner that appears to be synchronous, but with the +ability to suspend periodically in order to let other scripts have a +turn and prevent blocking the game loop. Building on top of the +scheduling that agendas provide, here is a script that models a child +trying to get their mother's attention: @example -(coroutine +(script (while #t (display "mom!") (newline) @@ -1275,67 +1275,66 @@ child trying to get their mother's attention: @end example This code runs in an endless loop, but the @code{wait} procedure -suspends the coroutine and schedules it to be run later by the agenda. +suspends the script and schedules it to be run later by the agenda. So, after each iteration of the loop, control is returned back to the game loop and the program is not stuck spinning in a loop that will never exit. Pretty neat, eh? -Coroutines can suspend to any capable handler, not just the agenda. -The @code{yield} procedure will suspend the current coroutine and pass +Scripts can suspend to any capable handler, not just the agenda. +The @code{yield} procedure will suspend the current script and pass its ``continuation'' to a handler procedure. This handler procedure could do anything. Perhaps the handler stashes the continuation somewhere where it will be resumed when the user presses a specific key on the keyboard, or maybe it will be resumed when the player picks up an item off of the dungeon floor; the sky is the limit. -Sometimes it is necessary to abruptly terminate a coroutine after it -has been started. For example, when an enemy is defeated their AI -routine needs to be shut down. When a coroutine is spawned, a handle -to that coroutine is returned that can be used to cancel it when -desired. +Sometimes it is necessary to abruptly terminate a script after it has +been started. For example, when an enemy is defeated their AI routine +needs to be shut down. When a script is spawned, a handle to that +script is returned that can be used to cancel it when desired. @example -(define co (coroutine (while #t (display "hey\n") (wait 60)))) +(define script (script (while #t (display "hey\n") (wait 60)))) ;; sometime later -(cancel-coroutine co) +(cancel-script script) @end example -@deffn {Procedure} spawn-coroutine @var{thunk} -Apply @var{thunk} as a coroutine and return a handle to it. +@deffn {Procedure} spawn-script @var{thunk} +Apply @var{thunk} as a script and return a handle to it. @end deffn -@deffn {Syntax} coroutine @var{body} @dots{} -Evaluate @var{body} as a coroutine and return a handle to it. +@deffn {Syntax} script @var{body} @dots{} +Evaluate @var{body} as a script and return a handle to it. @end deffn -@deffn {Procedure} coroutine? @var{obj} -Return @code{#t} if @var{obj} is a coroutine handle. +@deffn {Procedure} script? @var{obj} +Return @code{#t} if @var{obj} is a script handle. @end deffn -@deffn {Procedure} coroutine-cancelled? @var{obj} +@deffn {Procedure} script-cancelled? @var{obj} Return @code{#t} if @var{obj} has been cancelled. @end deffn -@deffn {Procedure} coroutine-running? @var{obj} +@deffn {Procedure} script-running? @var{obj} Return @code{#t} if @var{obj} has not yet terminated or been cancelled. @end deffn -@deffn {Procedure} coroutine-complete? @var{obj} +@deffn {Procedure} script-complete? @var{obj} Return @code{#t} if @var{obj} has terminated. @end deffn -@deffn {Procedure} cancel-coroutine @var{co} -Prevent further execution of the coroutine @var{co}. +@deffn {Procedure} cancel-script @var{co} +Prevent further execution of the script @var{co}. @end deffn @deffn {Procedure} yield @var{handler} -Suspend the current coroutine and pass its continuation to the +Suspend the current script and pass its continuation to the procedure @var{handler}. @end deffn @deffn {Procedure} wait @var{duration} -Wait @var{duration} before resuming the current coroutine. +Wait @var{duration} before resuming the current script. @end deffn @deffn {Procedure} channel-get @var{channel} @@ -1352,11 +1351,11 @@ Evaluate @var{body} in an endless loop. Tweening is the process of transitioning something from an initial state to a final state over a pre-determined period of time. In other words, tweening is a way to create animation. The @code{tween} -procedure can be used within any coroutine like so: +procedure can be used within any script like so: @example (define x 0) -(coroutine +(script ;; 0 to 100 in 60 ticks of the agenda. (tween 60 0 100 (lambda (y) (set! x y)))) @end example @@ -1369,8 +1368,8 @@ amount of time between each update of the animation. To control how the animation goes from the initial to final state, an ``easing'' procedure may be specified. By default, the @code{smoothstep} easing is used, which is a more pleasing default -than a simplistic linear function. @xref{Easings} for a complete -list of available easing procedures. +than a simplistic linear function. @xref{Easings} for a complete list +of available easing procedures. The @var{interpolate} procedure computes the values in between @var{start} and @var{end}. By default, linear interpolation (``lerp'' @@ -1380,23 +1379,22 @@ for short) is used. @node Channels @subsection Channels -Channels are a tool for communicating amongst different coroutines. -One coroutine can write a value to the channel and another can read -from it. Reading or writing to a channel suspends that coroutine -until there is someone on the other end of the line to complete the -transaction. +Channels are a tool for communicating amongst different scripts. One +script can write a value to the channel and another can read from it. +Reading or writing to a channel suspends that script until there is +someone on the other end of the line to complete the transaction. Here's a simplistic example: @example (define c (make-channel)) -(coroutine +(script (forever (let ((item (channel-get c))) (pk 'got item)))) -(coroutine +(script (channel-put c 'sword) (channel-put c 'shield) (channel-put c 'potion)) @@ -1411,11 +1409,11 @@ Return @code{#t} if @var{obj} is a channel. @end deffn @deffn {Procedure} channel-get @var{channel} -Retrieve a value from @var{channel}. The current coroutine suspends +Retrieve a value from @var{channel}. The current script suspends until a value is available. @end deffn @deffn {Procedure} channel-put @var{channel} @var{data} -Send @var{data} to @var{channel}. The current coroutine suspends -until another coroutine is available to retrieve the value. +Send @var{data} to @var{channel}. The current script suspends until +another script is available to retrieve the value. @end deffn -- cgit v1.2.3