src/interpreter.janet

@@ -345,7 +345,7 @@
         (set (the-dict key) value))))
   the-dict)
 
-(defn- box [ast ctx]
+(defn- ref [ast ctx]
   (def {:data value-ast :name name} ast)
   (def value (interpret value-ast ctx))
   (def box @{:^type :box :^value value :name name})
@@ -595,7 +595,7 @@
     # named/naming forms
     :word (word ast ctx)
     :interpolated (interpolated ast ctx)
-    :box (box ast ctx)
+    :ref (ref ast ctx)
     :pkg (pkg ast ctx)
     :pkg-name (word ast ctx)
 

src/ludus.janet

@@ -55,9 +55,8 @@
 # (do
  # (def start (os/clock))
  (def source `
-box foo = :bar
-store! (foo, :baz)
-unbox (foo)
+let foo = :bar
+let first = 1
  `)
  (def out (-> source 
   ludus

src/parser.janet

@@ -871,16 +871,16 @@
   (array/push data (capture simple parser)))
  {:type :do :data data :token origin})
 
-### boxs, pkgs, nses, etc.
-(defn- box [parser]
+### refs, pkgs, nses, etc.
+(defn- ref [parser]
  (def origin (current parser))
- (expect parser :box) (advance parser)
+ (expect parser :ref) (advance parser)
  (try
   (do
    (def name (-> parser word-only (get :data)))
    (expect parser :equals) (advance parser)
    (def value (nonbinding parser))
-   {:type :box :data value :name name :token origin})
+   {:type :ref :data value :name name :token origin})
   ([err] err)))
 
 (defn- pkg-name [parser]
@@ -1011,7 +1011,7 @@
 ### expressions
 # four levels of expression complexity:
 # simple (atoms, collections, synthetic expressions; no conditionals or binding or blocks)
-# nonbinding (excludes let, box, named fn: what is allowed inside collections)
+# nonbinding (excludes let, ref, named fn: what is allowed inside collections)
 # plain old exprs (anything but toplevel)
 # toplevel (exprs + ns, pkg, test, import, use)
 
@@ -1099,7 +1099,7 @@
   # binding forms
   :let (lett parser)
   :fn (fnn parser)
-  :box (box parser)
+  :ref (ref parser)
 
   # nonbinding forms
   :nil (nill parser)

src/scanner.janet

@@ -3,7 +3,7 @@
   ## see ludus-spec repo for more info
   {
    "as" :as ## impl
-   "box" :box
+   "box" :ref
    "do" :do ## impl
    "else" :else ## impl
    "false" :false ## impl -> literal word

src/validate.janet

@@ -343,7 +343,7 @@ Deferred until a later iteration of Ludus:
  (set (ast :arities) arities)
  validator)
 
-(defn- box [validator]
+(defn- ref [validator]
  (def ast (validator :ast))
  (def ctx (validator :ctx))
  (def expr (ast :data))
@@ -757,7 +757,7 @@ Deferred until a later iteration of Ludus:
    :use (usee validator)
    :loop (loopp validator)
    :recur (recur validator)
-   :box (box validator)
+   :ref (ref validator)
    (error (string "unknown node type " type)))))
 
 (set validate validate*)

turtle-graphics.md

@@ -67,15 +67,8 @@ But Ludus sending things to its output streams should only cause Ludus panics wh
 For pen-and-paper turtles, we don't have RGBA colors.
 Colors should also be specifiable with strings corresponding to CSS basic colors: black, silver, gray, white, maroon, red, purple, fuchsia, green, lime, olive, yellow, navy, blue, teal, and aqua.
 
-**Turtles should communicate states.** 
+**Turtles should maybe communicate states.** 
 Ludus should have access to turtle states.
 This is important for push/pop situations that we use for L-systems.
 There are two ways to do this: Ludus does its own bookkeeping for turtle states, or it has a way to get the state from a turtle.
-The latter has the value of being instantaneous, and gives us an _expected_ state of the turtle after the commands are all processed.
-In particular, this will be necessary for the recursive L-systems that require pushing and popping turtle state.
-The latter has the drawback of potentially allowing the turtle state and expected turtle state to fall out of synch.
-The former has the value of always giving us the correct, actual state of the turtle.
-It has the drawback of requiring such state reporting to be asynchronous, and perhaps wildly asynchronous, as things like moving robots and plotters will take quite some time to actually draw what Ludus tells it to.
-(Being able to wait until `eq? (expected, actual)` to do anything else may well be extremely useful.)
-That suggests, then, that both forms of turtle state are desirable and necessary.
-Thus: turtles should communicate states (and thus there ought to be a protocol for communicating state back to Ludus) and Ludus should always do the bookkeeping of calculating the expected state.
+