rename transform-state to transformation-state

this makes it unambiguously a noun phrase

Force-Push: yes
Change-Id: Ibc24821d70aaf6bc88ae5bf5e864e5b4db94dae5

1 files changed, 54 insertions, 52 deletions

diff --git a/transform.e b/transform.e
index 1230883..63ae9c1 100644
--- a/transform.e
+++ b/transform.e
@@ -241,27 +241,26 @@
       { drop zero-input-buffer-metadata } if-else ;
 
 
-~ TODO rename this to transformation-state
-: transform-state-saved-here ;
-: transform-state-saved-latest 8 + ;
-: transform-state-output-buffer-start 2 8 * + ;
-: transform-state-user-stack-depth 3 8 * + ;
-: allocate-transform-state
+: transformation-state-saved-here ;
+: transformation-state-saved-latest 8 + ;
+: transformation-state-output-buffer-start 2 8 * + ;
+: transformation-state-user-stack-depth 3 8 * + ;
+: allocate-transformation-state
   4 8 * allocate
-  dup transform-state-saved-here 0 swap !
-  dup transform-state-saved-latest 0 swap !
-  dup transform-state-output-buffer-start 0 swap !
-  dup transform-state-user-stack-depth 0 swap ! ;
-allocate-transform-state s" transform-state" variable
+  dup transformation-state-saved-here 0 swap !
+  dup transformation-state-saved-latest 0 swap !
+  dup transformation-state-output-buffer-start 0 swap !
+  dup transformation-state-user-stack-depth 0 swap ! ;
+allocate-transformation-state s" transformation-state" variable
 
 
 ~   When calling the label facility during a transformation, it's necessary
 ~ to use the real, non-wrapped "here" and "latest".
 : swap-transform-variables
-  here @ transform-state transform-state-saved-here @
-  here ! transform-state transform-state-saved-here !
-  latest @ transform-state transform-state-saved-latest @
-  latest ! transform-state transform-state-saved-latest ! ;
+  here @ transformation-state transformation-state-saved-here @
+  here ! transformation-state transformation-state-saved-here !
+  latest @ transformation-state transformation-state-saved-latest @
+  latest ! transformation-state transformation-state-saved-latest ! ;
 
 ~   We deal with a few address spaces. There's the "host" address space, the
 ~ space this process performing the compilation is using for itself. There's
@@ -295,12 +294,12 @@ allocate-transform-state s" transform-state" variable
 ~ (output offset -- host address)
 : offset-to-host-address-space
   ~ Don't transform null pointers
-  dup { transform-state transform-state-output-buffer-start @ + } if ;
+  dup { transformation-state transformation-state-output-buffer-start @ + } if ;
 
 ~ (host address --output offset)
 : host-address-space-to-offset
   ~ Don't transform null pointers
-  dup { transform-state transform-state-output-buffer-start @ - } if ;
+  dup { transformation-state transformation-state-output-buffer-start @ - } if ;
 
 ~ (host address inside the output buffer -- target address)
 : host-address-space-to-target
@@ -314,12 +313,15 @@ allocate-transform-state s" transform-state" variable
 : describe-transformation
   ."        active here " here @ .hex64 space
   ." latest " latest @ .hex64 newline
-  ."         saved here " transform-state transform-state-saved-here
+  ."         saved here " transformation-state transformation-state-saved-here
   @ .hex64 space
-  ." latest " transform-state transform-state-saved-latest @ .hex64 newline
-  ."       output start " transform-state transform-state-output-buffer-start
+  ." latest " transformation-state transformation-state-saved-latest
   @ .hex64 newline
-  ."   user stack depth " transform-state transform-state-user-stack-depth
+  ."       output start "
+  transformation-state transformation-state-output-buffer-start
+  @ .hex64 newline
+  ."   user stack depth "
+  transformation-state transformation-state-user-stack-depth
   @ .hex64 newline ;
 
 
@@ -330,7 +332,7 @@ allocate-transform-state s" transform-state" variable
 ~ use, or not, as they prefer, called user stack depth tracking. The log-load
 ~ transform uses it; the label transform does not. The most difficult part of
 ~ the tracking is the heler word below; it also relies on the user-stack-depth
-~ field of the transform-state variable.
+~ field of the transformation-state variable.
 ~
 ~   What does user stack depth mean? Well, for every transform there's some
 ~ notion of running a word "immediately"; for the log-load transform, it means
@@ -811,7 +813,7 @@ allocate-transform-state s" transform-state" variable
   dup s" L@'" stringcmp 0 = { drop 1 exit } if
   dup s" L!'" stringcmp 0 = { drop -1 exit } if
   dup s" labels" stringcmp 0 = { drop 1 exit } if
-  dup s" allocate-transform-state" stringcmp 0 = { drop 1 exit } if
+  dup s" allocate-transformation-state" stringcmp 0 = { drop 1 exit } if
 
   ~   If we get here, that's a problem. Emit an error message to make sure
   ~ it's easy to diagnose. We also return a comically large negative value,
@@ -822,8 +824,8 @@ allocate-transform-state s" transform-state" variable
 
 ~ (delta --)
 : transform-apply-stack-delta
-  transform-state transform-state-user-stack-depth @ +
-  transform-state transform-state-user-stack-depth ! ;
+  transformation-state transformation-state-user-stack-depth @ +
+  transformation-state transformation-state-user-stack-depth ! ;
 
 
 ~ Label transform implementation
@@ -1241,7 +1243,7 @@ allocate-transform-state s" transform-state" variable
   ~ If not, we look up the word in the regular, non-transformed dictionary
   ~ and use that for immediate mode.
   over { dup
-         transform-state transform-state-saved-latest @ swap find-in
+         transformation-state transformation-state-saved-latest @ swap find-in
          3roll drop swap } unless
   ~ (name as stack string, immediate entry pointer, name pointer)
 
@@ -1404,9 +1406,9 @@ allocate-transform-state s" transform-state" variable
   ~ since client code will make its own updates to them and then rely on those
   ~ updates having taken effect. So we do the swap just once, here outside the
   ~ loop, and set it back when the loop ends.
-  here @ transform-state transform-state-saved-here !
-  latest @ transform-state transform-state-saved-latest !
-  over transform-state transform-state-output-buffer-start !
+  here @ transformation-state transformation-state-saved-here !
+  latest @ transformation-state transformation-state-saved-latest !
+  over transformation-state transformation-state-output-buffer-start !
   here !
   0 latest !
   ~ Now the stack has nothing of ours on it, so client code can do its thing.
@@ -1421,15 +1423,15 @@ allocate-transform-state s" transform-state" variable
     ~ back. The internal "here" is also the output point, and will become our
     ~ return value. The internal "latest" is discarded.
     { here @
-      transform-state transform-state-saved-here @ here !
-      transform-state transform-state-saved-latest @ latest !
+      transformation-state transformation-state-saved-here @ here !
+      transformation-state transformation-state-saved-latest @ latest !
       ~ (output point)
 
-      ~   Though we don't actually use transform-state outside of this
+      ~   Though we don't actually use transformation-state outside of this
       ~ invocation, for tidiness we zero it out.
-      0 transform-state transform-state-saved-here !
-      0 transform-state transform-state-saved-latest !
-      0 transform-state transform-state-output-buffer-start !
+      0 transformation-state transformation-state-saved-here !
+      0 transformation-state transformation-state-saved-latest !
+      0 transformation-state transformation-state-output-buffer-start !
 
       ~  Also put the input source back how it was.
       main-input-buffer pop-input-buffer
@@ -1515,7 +1517,7 @@ allocate-transform-state s" transform-state" variable
 ~ to put the log address on top, as preparation for calling something that
 ~ relies on it.
 : log-load-roll-log-address
-  transform-state transform-state-user-stack-depth @
+  transformation-state transformation-state-user-stack-depth @
   ~   The amount we're rolling includes the log address, which is not a user
   ~ value, so we add 1.
   1 +
@@ -1526,7 +1528,7 @@ allocate-transform-state s" transform-state" variable
 ~ to put the log address back at the bottom, as cleanup after calling
 ~ something that relies on it.
 : log-load-unroll-log-address
-  transform-state transform-state-user-stack-depth @
+  transformation-state transformation-state-user-stack-depth @
   ~   The amount we're rolling includes the log address, which is not a user
   ~ value, so we add 1.
   1 +
@@ -1537,7 +1539,7 @@ allocate-transform-state s" transform-state" variable
 ~ to put the saved label value on top, as preparation for calling something
 ~ that consumes it.
 : log-load-roll-saved-label
-  transform-state transform-state-user-stack-depth @
+  transformation-state transformation-state-user-stack-depth @
   ~   The amount we're rolling includes both the log address and the label
   ~ value, neither of which are user values, so we add 2.
   2 +
@@ -1548,7 +1550,7 @@ allocate-transform-state s" transform-state" variable
 ~ to put a saved label value on the bottom, as a way of safely storing it away
 ~ when it's newly generated.
 : log-load-unroll-saved-label
-  transform-state transform-state-user-stack-depth @
+  transformation-state transformation-state-user-stack-depth @
   ~   The amount we're rolling includes both the log address and the label
   ~ value, neither of which are user values, so we add 2.
   2 +
@@ -2142,7 +2144,7 @@ allocate-transform-state s" transform-state" variable
 ~ the transformed code is expected to have on the stack, based on its
 ~ hardcoded understanding of each word that's expected to be relevant, looked
 ~ up by the word's name. The number of items is stored in the user-stack-depth
-~ field of transform-state.
+~ field of transformation-state.
 ~
 ~   There is no adjustment done on the saved value, since it's created in the
 ~ target address space and then also used in the target address space. It
@@ -2512,11 +2514,11 @@ allocate-transform-state s" transform-state" variable
   ~ loop, and set it back when the loop ends.
   ~
   ~   We also take this opportunity to initialize the output-buffer-start and
-  ~ user-stack-depth fields of transform-state.
-  here @ transform-state transform-state-saved-here !
-  latest @ transform-state transform-state-saved-latest !
-  over transform-state transform-state-output-buffer-start !
-  0 transform-state transform-state-user-stack-depth !
+  ~ user-stack-depth fields of transformation-state.
+  here @ transformation-state transformation-state-saved-here !
+  latest @ transformation-state transformation-state-saved-latest !
+  over transformation-state transformation-state-output-buffer-start !
+  0 transformation-state transformation-state-user-stack-depth !
   here !
   0 latest !
   ~ Now the stack has nothing of ours on it, so client code can do its thing.
@@ -2531,16 +2533,16 @@ allocate-transform-state s" transform-state" variable
     ~ back. The internal "here" is also the output point, and will become our
     ~ return value. The internal "latest" is discarded.
     { here @
-      transform-state transform-state-saved-here @ here !
-      transform-state transform-state-saved-latest @ latest !
+      transformation-state transformation-state-saved-here @ here !
+      transformation-state transformation-state-saved-latest @ latest !
       ~ (output point)
 
-      ~   Though we don't actually use transform-state outside of this
+      ~   Though we don't actually use transformation-state outside of this
       ~ invocation, for tidiness we zero it out.
-      0 transform-state transform-state-saved-here !
-      0 transform-state transform-state-saved-latest !
-      0 transform-state transform-state-output-buffer-start !
-      0 transform-state transform-state-user-stack-depth !
+      0 transformation-state transformation-state-saved-here !
+      0 transformation-state transformation-state-saved-latest !
+      0 transformation-state transformation-state-output-buffer-start !
+      0 transformation-state transformation-state-user-stack-depth !
 
       ~  Also put the input source back how it was.
       main-input-buffer pop-input-buffer