Upcoming Versions

By 0.1.0

Core System

Prefatory work:

• DONE Start out by getting it to write a plan for rebuilding TOP on Qwiratry, so that I can start work on that when I run out of credits

• DONE Fix the current problem, sort out what we currently have and do a commit

Rejigging:

• DONE Would it make sense to combine Walkers and Navigators? Would there be efficiency gains by doing that?

Testing:

• DONE Ask it if we have (functional) tests based on the Specification

• DONE Make test suites for testing formats/locations that can be run against any new format/Location

• DONE Ensure it combines well with feed operators

New features:

• DONE Have it do at least a little testing to figure out why it's so slow

• DONE As a fallback, if there's no Format/Location, can we look up recommended packages in zef, so that if a format is missing, it recommends to people that they can install it

• DONE Use Matches as the tree as well as RakuAST

• DONE Make a qwiratry-setup script that asks which formats/locations you'd like to install (after querying zef/ecosystem to find what's available); lets you tick the ones you want, and then it'll install them

Modules

• Locations:

  • DONE: Filesystem -- if someone uses file:/ or something with no : on a directory, then assume that we're treating that as a root for find/navigation; treat files and directories differently; test out regex/glob matching

• Formats

  • DONE: JSON

  • DONE: YAML

  • DONE: XML

  • INI

  • TOML

  • XKB in conjunction with writing an article about it (cf. articles)

• DONE Ensure that everything (including raku-Qwiratry-Test) is pushed to fez/github

Tweak ideas

Maybe do these:

• DONE: Allow IO::Handle on LHS of parse op (for STDIN)

• DONE: If nav op (including attribute) doesn't have a LHS, use $_

Streamable Trees

Core System

Making things Streamable; cf. both:

• Streaming-Qwiratry-Proposal.rakudoc (in this directory)

• https://wayland.github.io/table-oriented-programming/Metanoias/Walkable-vs-Streamable.xml

Table-Oriented Programming (this may be multiple versions)

• Rewrite my existing TOP code to use Qwiratry; include Human and Half-Human formats as part of core; will likely need CSV to implement Human format, so maybe only include Half-Human as part of core?

• Break out some of the parts into modules; SQL encoding should probably remain in core though

• Could probably do ods files at this point

Benchmarking

• Do some benchmarking, and do a comparison of a basic pipeline compared with normal code, and see if we can't do something to speed it along

Stylesheets

CSS

Do this at some point, because it really needs to be read in as transformers/molds

XSLT

See if we can read this in as transformers/molds as well.

Ideas to Consider

This records architectural ideas that are potentially useful, but are not part of the current implementation plan. Notes here are intentionally tentative.

Declaraku

Some of these ideas might be better as part of Declarative Raku, but not Data-Oriented Programming.

Revisit Declaraku ideas, including:

• Logic Programming Integration

• Queries being the inverse of functions

• Dependent Programming (cf. Puppet and Makefiles); everything runs simultaneously, except the stuff that's dependent on other stuff

• Read https://chatgpt.com/c/6a537baa-cd8c-83ec-87b6-407118618bc3 -- Picat has already done some of the hard work. Skip the first Q&A, the answer to the second question is better, and it only gets better from there. Also skip the explanation of BFS and DFS

  • Possibly we want to have functions be able to declare "cache all results, and if I'm re-called with the same parameters, return the same value". We don't want to do that for everything, but could sometimes be handy for eg. goal-seeking.

  • The "Logic Variables" also sound cool and implementable. Maybe not part of Data-Oriented Programming though.

Semantic Pattern Extractors

Domain-specific pattern extractors could provide higher-level matching vocabulary above ordinary tree navigation.

The navigator layer answers structural questions such as "what are this node's children?", "what is its parent?", or "what attributes does it expose?". Pattern extractors would answer semantic questions for a particular domain.

Possible examples:

• RakuAST: match a call by name, an infix operator by symbol, a literal by value, or a declaration by kind.

• XML: match an element by name, an attribute by name or value, a namespace, text nodes, or processing instructions.

• HTML/XHTML: match a tag, CSS class, ID, link target, form field, or heading level.

• JSON-like config data: match an object with a key, a key path, or a dependency declaration.

These should probably sit above navigators rather than inside them. A navigator should expose structure consistently; a semantic extractor can then interpret that structure for a domain.

Open questions:

• Whether extractors should be ordinary functions, query operators, mold helpers, or registered domain services.

• Whether extractors should produce query AST fragments or just predicates.

• Whether extractors belong with domains, formats, or transformer libraries.

Stratego-Like Traversal Combinators

Stratego separates rewrite rules from traversal control. It provides primitive one-step traversal operations such as applying a strategy to all, one, or some children, and builds reusable traversal schemes such as top-down, bottom-up, once-top-down, and innermost rewriting.

Qwiratry already has a Strategy layer with hooks for before, on-match, should-follow, after, finish, and should-continue. It also has Walker plans and iterators controlling traversal. If Stratego-like combinators are added, they should probably build on that existing model rather than replace it.

Possible directions:

• Provide named traversal helpers for common schemes such as top-down, bottom-up, fixed-point, and first-match.

• Let transformer methods compose strategy behavior for a specific transform.

• Treat these combinators as convenience APIs over Walker/Strategy behavior, not as a separate traversal engine.

Open questions:

• How failure/backtracking should be represented in Raku.

• Whether combinators belong on Strategy, Transformer, Walker::Plan, or a new traversal utility module.

• How they should interact with existing ControlSignal values and rewrite modes.

K Semantic Framework-Inspired Ideas

K uses configurations, labeled cells, local rewriting, contexts, and "anywhere" rules to define executable semantics. These ideas may become useful if Qwiratry grows from structural transformation into semantic transformation over larger program states.

Possible directions:

• Model a transform target as labeled regions or cells, allowing rules to mention only the relevant part of a larger state.

• Support local rewrites that explicitly identify which parts of a structure are read, written, or ignored.

• Add "anywhere" style rules for cases where a rewrite should apply wherever a matching term appears.

• Explore context abstractions for evaluation-order or normalization tasks.

These ideas are deliberately deferred. They are probably too heavy for the current tree navigation and format navigator work, but worth keeping in mind for future semantic rewriting features.

Postponed until Raku integration

• POSTPONED See if we can rejig things so that we only need one “use” statement; can the Slangs be merged into the main Qwiratry module (and then load other modules on demand)? This would be trickyish -- might be best to wait until we merge them into the language.