﻿		MOVED TO THE POD:

Maybe use caching counters to automate conversion of `callbacks` from a string to a hash of subroutines???

Need a test which merges peano with infix, then one implementing all of 50-54 basing only on unary and Peano primitives.  m4???

Document which parts of "Fab/" Config are accessed through an explicit path, and which through a dynamic one.

  A conflict between installable components's names may arise; so they need to allow redefinition of the name/prefix they use.  Or:
  they requestion "Foo", get back "Foo12" (so the requested name should not end in a digit).

Efficient replacement for FreezeThaw.  Handle DAG config - but probably not an arbitrary graph with weak links inside???  Handle a
tree and the knowledge of where is the gluing of branches???

Are groups with partial config-undo-on-exit documented/implemented yet???

How switching the filter interacts with dynamic switching of Fabs???  Where the switched filter stores its data: explicitly in
subsets of config???  Interaction with dynamic parts of the config???  Compartmentalization of config???

How to indicate resolution in the caller/callee namespace???  What is the default now???

How to decide which promises are expanded now, and which "pass through" unchanged?

Traceback of provenance of errors in presence of promises???  Traceback of who created the promise in its metadata???

User-configurable logging/debugging output???

For postponed actions need an extra argument "ignore errors": with 2 would just put into eval, with 1 converted to a warning,
negative values stop the remaining undo actions for that many frames (with -2 stopping for the current frame and one more).

One needs to prohibit __get()ing a reference.  Use __getref() when you expect a reference (but no checks for reference are
performed).

MISS: input__end($n) with $n==0 ending the current input stream, or also $n enclosing streams.

MISS: need to specify what happens with a group on input__end(): survives / should be closed before / close-if-still-open.

MISS: input__end_to($group_type): end input of the files opened up to the the opened-latest-group of the given type.

  Likewise for “closing enclosed groups”???  Join together into 1 API by introducing suitable groups???

    May run forever???  Even the language if group__start, group_end, group__postpone (with the arguments to the last command
    restricted to these 3 calls) is probably Turing complete???

MISS: _-prefixed versions of config__*() which check the prefix _ __ ___ of the key and make it read/write only.

MISS: pipelining preprocessor with “filters”: filters consists of 3 components: preprocessor, massaging of promises, and the
      concatenator of the resulting candidates-for-sections.

Uplevel w.r.t. the recursion stack should be recalculated into the usual uplevels; a special do-nothing group may be used.

allow not 1 active preprocessor engine, but a stack of them, chained, and have a cfg__pop() primitive method.

Macros are templates marked as OK-to-be-ignored.

Hash to mark macros as “types”, with per-type-warning configurable?  Which way to hash, types to macros, or macros to types, or
pairs???

An extra parameter $is_replay for the syntax callbacks for the non-first pass.  (Probably, the boundary of the preceding pass cannot
be part of this???

hash keys.  Setting/getting them employs a serialization method, by default JSON???
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!	THIS IS TOO DANGEROUS.
					Access control to Fab/* keys should be guarded by ungettable/settable types of values ???

#unset — but maybe it is going to make undo harder???

Recursive invocation is needed for massaging data between different levels:
  • The hash
  • Input file names
  • Input strings
  • Output sections

A top→down approach to recognizing the “reconfiguration directives”: but cannot
we support a bottom→up approach too, when the preprocessor recognizes interlaced
directives?  How to deal with recursion: return an indicator that the state
changed?  But it is changing permanently, one needs to filter out changes — but how
the internal calls know the filters needed for the enclosing calls???

the preprocessor needs a guarantee that it is going to be reentered

---

The default mode of process is equivalent to writing to a buffer __default__, and at the end executing the file
	= = = = = filterbuffer(raw) __default__
Doing the same abstraction once more, the buffer with that contents may be also created dynamically, then loaded via filterbuffer().
On the gripping hand, this may be also
	= = = = = filterbuffer(raw) __default__pre
	= = = = = filterbuffer(raw) __default__
	= = = = = filterbuffer(raw) __default__post
With (initially) empty buffers __default__pre and __default__post (to which one has a chance to write later!).  And what one
writes to these buffers may be triplicated likewise.  Etc.

=========================== DONE/OBSOLETE beyond this point

Docs are not cleaned up (mark these by “???”!); and parts are still missing.

cfg__set() with a scalar key should fail with more than 1 values to set.

What if no $offset and list???
	Passing C<$offset> on a non-list key halts with C<E_TYPE_MISMATCH>.

When undoing, undo data should be guarded, at least up to the exit.

====================

uplevel should allow execution AFTER the group is closed

There should be an indicator that a method is called “from” before/after uplevel.  If uplevel is called “uplevel”ed, it should
only register the requests,; at end of the enclosing processing of the uplevevel-ed stuff, these postponed commands should be
executed (reversing order again???).

  Should reversing of order be customizable, and in which order one should put the inverted group and the non-inverted group????
  Probably better to have more than 2 types, and for every “type” have the pre/post specified, and whether upleveling from the
  group reverses the order???

  The type is a Unicode string starting with either PRE-, or post-, and sorting as if it is appended by ".000"… with an infinite
  number of characters '0' (but before the possible suffix "-inv".  Then sorting lexicographically (with actual closing happening
  between PRE- and post-, and -inv groups inverted gives the order of execution.  (Still: inversion of postponed postpones???)

  When sorting, one can literally pad by ".0"* up to the maximal length of the name of existening groups + 1!

    Note that "string#" comes before "string" for any value of "string", and different strings “sort differently”!

  The current docs mix pre/post semantics.

    Status Details:
      • DONE: Clean, non-heuristic API: group__postpone($depth, $priority, $how, $method, @args).
      • DONE: Real-number priority: < 0 executes PRE-undo (before rollback), 0.0 is the
        rollback point, >= 0 executes POST-undo (in restored enclosing scope).
      • DONE: User-selected 'append' vs 'prepend' controls execution order within equal priorities.
      • DONE: Two-level execution architecture:
          - Level 1: Sorted array of priority indices (@priorities).
          - Level 2: Hash of internal arrays ($top->{postponed_by_prio}).
          - Fast path: sequential shift from current internal array. Insertions into existing
            present/future buckets push/unshift directly without recalculation.
          - Slow path: insertions in the past (time machine) or into newly created future priorities
            route to $top->{extra_prio} and trigger index recalculation on demand.

