Compare commits

...

2 Commits

Author SHA1 Message Date
Scott Richmond
df85be3c1e ref->box everywhere 2024-07-21 16:31:20 -04:00
Scott Richmond
60106d10f0 consider turtle-reported vs. expected-calculated state 2024-07-21 16:26:56 -04:00
6 changed files with 23 additions and 15 deletions

View File

@ -345,7 +345,7 @@
(set (the-dict key) value))))
the-dict)
(defn- ref [ast ctx]
(defn- box [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)
:ref (ref ast ctx)
:box (box ast ctx)
:pkg (pkg ast ctx)
:pkg-name (word ast ctx)

View File

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

View File

@ -871,16 +871,16 @@
(array/push data (capture simple parser)))
{:type :do :data data :token origin})
### refs, pkgs, nses, etc.
(defn- ref [parser]
### boxs, pkgs, nses, etc.
(defn- box [parser]
(def origin (current parser))
(expect parser :ref) (advance parser)
(expect parser :box) (advance parser)
(try
(do
(def name (-> parser word-only (get :data)))
(expect parser :equals) (advance parser)
(def value (nonbinding parser))
{:type :ref :data value :name name :token origin})
{:type :box :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, ref, named fn: what is allowed inside collections)
# nonbinding (excludes let, box, 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)
:ref (ref parser)
:box (box parser)
# nonbinding forms
:nil (nill parser)

View File

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

View File

@ -343,7 +343,7 @@ Deferred until a later iteration of Ludus:
(set (ast :arities) arities)
validator)
(defn- ref [validator]
(defn- box [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)
:ref (ref validator)
:box (box validator)
(error (string "unknown node type " type)))))
(set validate validate*)

View File

@ -67,8 +67,15 @@ 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 maybe communicate states.**
**Turtles should 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.