Thinking about Mechs

We're looking for a mechanism that lives on federated wiki pages and provides functionality somewhere between our existing plugins and the html scripting enabled by the Frame plugin.

.

The most valuable thing a new interpreter could offer is uniform and tolerant exception handling. We will try rewriting some recent scripts in the most concise way we can imagine recursively evaluating while leaving error detection, reporting and recovery to the evaluator.

SEARCH SLUG item-type-survey REPORT sites SELECT survey HAS map EACH REVISE site SUMMARY count DETAILS LIST title count LINK

.

Paul suggested Snap right off the bat. I had to relive my history with blocks before I was ready to study it. pdf

I'm now 15 pages into this pdf and I have come to an important realization: blocks provide a structure editor, true, but they also provide a control panel for the running program.

This is important because we have the same control available even if we use plain text for "markup". The rendered markup can include all kinds of dom based interactions. I was assuming a button would be a natural thing but it could be even more "natural" to just click on the rendered keyword.

.

The block-based systems get most of their semantic power from a rich catalog of parameterized blocks. I imagine a Mech plugin would consist of a parser-evaluator combined with an easily expanded collection of blocks, probably javascript modules.

We walk a tightrope between power and security whenever we implement in javascript. So the blocks should be bundled with the plugin and configured and installed by the site administrator.

I imagine each chapter of the block catalog will have a javascript module and an about page describing how these particular blocks are to be used.

A chapter should offer blocks meeting quality standards that exceed what we usually expect of html scripts. They thus earn the right to escape the iFrame sandbox. We will need a block specific unit-testing methodology while experimental blocks should be easy to make and run untested in localhost.

.

Following in the footsteps of Logo, block systems start with numbers and strings but quickly layer on turtle graphics with blocks for move and turn. What things and services will we need to blockify?

Sourced Datatypes: markers for Maps, named values for Method, aspect graphs for Solo, vectors for Radar, time series for Line.

Ambient Structures: pages, items, sites, lineup and sourcemaps. Eventually search and surveys.

Familiar Assets: managed assets like those of Image and Datalog. Exports from well known tools like arrows.app.