notes

Evolution Notes.

The basic idea is to only change something if it makes sense and it's simple. It must be simple and elegant.

The goals of the project are to make it easy to create a very configurable and repeatable process which is python code at it's heart. Processes should be able to fail gracefully, and report what they know.

For me, it is very interesting to see how the solutions refine themselves under such limited abilities. I'm interested how the -from, -to and -with stuff will affect the creation of stuff in the data tree. I think with those constructs there will not be as much need for special data spots. The way I was originally thinking when I added the markdown stuff. That'll change in a minute.. markdown will be like the new ones soon.

Because of the restrictions of the appstate, or thinking of it as an app state, and configuration instead of just namespace, things changed dramatically with that change of point of view.
Now, set-in is making variables, we are just stashing them in a big global tree.

It's feeling lot like a language...

Set_in, get_in and showin, were originally modeled after clojure's update-in, and get-in. But now they use paths instead. Now it feels much more intuitive to wander around the system space with ls and show. The interface to values also became simple.

The python representation changed like so. [foo bar baz] Became: foo/bar/baz.

And the evolution of set evolved from set-in and a dorky set-in-from

set-in foo bar baz 10
set-in-from foo baz from: foo bar baz

to this, - just set:

set foo bar baz 10

set foo baz from: foo bar baz

to this:

`set foo/bar/baz 10`
`set foo/baz  /foo/bar/baz`

The idea of -from and -to changed things too, those are essentially all that is needed within a module for it to get the stuff to and from other module's, yaml datastore, or where ever you are putting your stuff.

But that led to -with variants, so now, we give a path full of stuff to a function and it goes and gets what it wants with what you have there.

So, I'm not sure where that's headed, but it seems like that could boil away too. A with function, and the lower level python code in every module goes away.

But the interpreter really hasn't changed, and it's way more stupid than the dumbest of lisp interpreters. And they can be pretty stupid too.

I added barcodes to SPR because that was a requirement for a thing I made for someone. When I did that, I decided to add simple namespaces, which led to just changing everything from the stupid simple and obvious symbol tables to a more elegant import system.

Because of namespaces and import, instead of a big ol YAML, each module could keep it's own little piece. Simpler and Simpler.

These things changed everything, but the language, if you can call it that, It's only syntax is whitespace, and I guess we can count the /'s in the paths. hasn't changed.

And despite it's growing capabilities it's doing it with less code. That's cool.

I sort of want to give a choice of repl's so more fun could be had that way. And why not have a repl server and an emacs mode so I can run spr code in emacs. And I'd like to see this with plysp as it's REPL.

So, endless fun. Why not.

Ok, so comments, and inline Yaml. These are nice things.

With is coming, it's in my head swimming around.

With is here, almost. it works in appstate. the repl needs to bind with it. Adding push and pop so we have stacks and lists. so with is implemented with SPR. cool.

Result stacks,....

Working!!!! Deleted bunches of code.

And 2.0 is out. it works. With is cool, parameter binding is cool, push and pop, python code is disappearing. Functions can be made by eval of a list. cool!!

Fri Aug 20 08:03:38 PM EDT 2021

That last one was a few months ago. Got my eyesight back last week.

With stack and scoping works. functions defined ala Yaml work. They get saved as a uuid/gensym and the dolist just has the gensym as it's its function value.

    def foo "my foo func"
    '
    - cli/msg hello
    - cli/msg goodbye

I've refactored the particle board stuff, it deleted the entire top level python code. That was all the real interface in PBR. The SPR code that replaced it is minimal and I think most of it can go away too.

I think with all the new stuff, it's just time to refactor all the modules again. Dialogs and cli can be simplified I think. Device needs some love.

I need to see how the code patterns fall out.

Then I can wrap up the PBR stuff.