Compare commits

..

No commits in common. "df85be3c1e36b0d2910de1985c52d06e428ab98d" and "e0680593629f7160a30ffc0c0220aef6d69c23ba" have entirely different histories.

6 changed files with 15 additions and 23 deletions

View File

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

View File

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

View File

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

View File

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

View File

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

View File

@ -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. 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. 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. Ludus should have access to turtle states.
This is important for push/pop situations that we use for L-systems. 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. 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.