I.e., invariants as a way to specify database validity criteria, which grants knowledge about which txes are safe to run in parallel and which need to run on top of each other.

I.e., having tx results as CRDT allows to merge them. But this is only possible if one tx does not change read deps of the other tx. Otherwise the result of the other tx would be ivladit, and would be invalid to merge it. It would need to be re-run on top. E.g., for cases where double-spend can occur.

Note: when all txes use CRDTs. When there is a non-CRDT tx it may fail.

Non-CRDT tx is akin to a snapshot. Multiple snapshots for the same cannot exist within a block if you don't have rules on how to merge them (approach described in XOX paper for post-order execution).

CRDT ops can be applied on top of a snapshot.

snapshot cannot be applied on top of CRDT.

So a block with non-CRDT and CRDT ops seems to only be fully valid if it has snapshot first and then CRDT deltas on top.

As shown by XOX, it's possible to retain conflicting transactions and perform them on top of detected "happened before" ones.

Malicious voter may issue votes with no Vote1 "happened-before" Vote2. If we have 2 of 4 endorsment reuqirement, then he can send Vote1 to two orgs and Vote2 to the other two. Both sets of orgs will endorse the vote.

Seems it may be tackled by imposing 3 of 4 as endorsement threshold.

Or, in general case, > 1/2 orgs.

Given orgs may be malicious (faulty), we can take it into an account by setting fault threshold. Say to 1/4.

Then endorsement threshold will be: ((1/2 + 1/4) +1) * number of orgs.

Or, in general case, endorsement theroshld = ((1/2 + fault threshold) + 1) * number of orgs

I.e., external oracles are read deps as of pre-order execution step.

Note: RW of dependee transaction overlaps with W of dependent transactions. As clarified later in the paper.

Or any other determenistic compute. Such as Docker, or Nix, Guix, IPVM.

Binary search as an alternative

Seems it makes possible to double-spend.

Can we avoid the problem of selecting MVs by treating each query as AST, preserving it's results? And so a set of queries would form a forest of ASTs, where shared nodes would only be computed once.

Nodes become MVs.

Interestingly, a node may be only partially computed.

E.g., if there is a join node AB that joins A and B nodes, then A could be fully computed, and B could be computed only to find matching results for AB pivot.

Although here we mix logical representation of node A, node B, and a pivot node AB, pivot(A, B), with it's physical representation of join(A, B) and it's optimisation join(A, B(A)), where B(A) is B based on results of A, which resembles embedding A and AB, rather than A, B, AB.

These are different ASTs. B based on A not= B.

All in all, out of logical queries physical ASTs can be derived that are optimized for those queries.

Perhaps having embeddings as joins is optimal. E.g., AB = join(A, B(A)) ABC = join(AB, C(AB))

Residial patterns could have indexes created for them on-the-fly as overlapping embeddings. Making use of precomputed solutions of those embeddings.

So during query processing we don't seek matches for all residual patternss and join afterwards, dropping some of the matches. Rather we query for matches based on embedding matches, so we don't get "to be dropped" matches at all.

This is an approach on "how to efficiently compute join of embeddings". And it's about having a "join embedding" that joins based on most-restrcitive embedding first. I.e., that embedding that has less matches or, if embeddings haven't been computed yet - that embedding that is expected to be most restrictive (e.g., because it has most restrictive BGB).

I.e., covers with overlapping embeddings allow better cost saving estimation than covers with non-overlapping embeddings.

This query could have its own index. Making use of (c) and (d) to maintain it's results by joining their solutions.

I.e., there can be an index per query. Query patterns would be broken down to embeddings for the most efficient compute of queries.

I.e., query as an AST of embeddings.

An extensional overlap is the one not made intensional.

Extensional overlaps can be made intensional overlaps.

And maintained in the same way.

The notation is meh.

Alternative:

G - graph

P - pattern

S - solution

I - index

EI - eligible index

EIs = ei(P, I) - eligible indexes I for P

?c would contain all ?y. Since ?y is a more restrictive pattern than ?c.

I.e., it may be possible to adopt some of the ?y matches for ?c.

Not only be contained, but exactly match.

Alternative approach is to create indexes at arbitrary time, e.g., after query execution.

Then, during query execution available indexes are used. And the result can always be indexed as one needs.

This would speed up query execution. As there is no cost of index creation and maintenance at this stage.

|O| would be more uniform in style, akin to |P|.

Or O(P(Q), G), |P(Q)| - size of query, |O(P(Q), G)| - size of solutions.

Or, in polish notation, (O (P Q) G).

I.e., O = solutions of P.

I.e., a BGP.

I.e., tripple pattern reified in RDF.

Perhaps would be nice to have that as optimization at the query engine level?

A naive approach is to have MV per each intersection of queries.

Enumirating all possible MV combinations in order to find the best one found impractical.

Resembles "Partial Materialized Views" approach used by SageDB.

.

A fine dot.notation interface for delta-based CRDT

Ehh. Isn't author+deps enough?

Ehh, why?

This node has been marked as deleted and has"done" true field. Why is this field leaked out of the deleted node?

Data Laced with history gets it right by having data structure as AST. Where you'd have a node with this field, and that has been marked as deleted, resulting in node and all its fields "deleted".

Collaboration = keep all edits and merge them

I.e., use Hypercore to maintain a personal website. Use Aggregore as browser.

This makes autobase view not just a view.

Why isn't it done in one of the inputs?

Hypercore bundles CRDT with p2p.

It is akin to OrbitDB's db, if only it'd have one writter.

OrbitDB is a toolkit, where you can assemble your CRDT p2p solution. Making use of components: - ipfs-log as base for your CRDT - libp2p as base for your p2p - auth to manage readers and writters

Whereas Hypercore seems to bundle it all up.

Welp, what can we do when an op does express intent that depends on multiple others? E.g., transferm money from Bob to Alice

Welp, would be nice to have author inside the operation.

Lamport timestamp doesn't seem to add any new information. It's an idx of op, which can be derived from the longest chain of its parent if needed.

Wall clock is useful. It's akin to "decision time".

Wall clock + author would be enough for uniqueness of operptons. And linking can be done by hash.

Perhaps an alternative way is to have a tx log on each devices - which will only be accreted with newly observed ops. Then it's order never changes and we can use idx as identifiers that stay evergreen.

Reminds of the techinque WasmTree uses, where an internal representation of RDF nodes replace URLs with an integer ID and has a map to resolve URLs back.

Except that here we use idx of a log entry in place of its UUID. Which requires to update mapping on merge of new ops. Whereas by having integer ids in entries, in place of UUIDs, we would be spared from that. Con is that there is a storage cost to store those integer ids. Which is lower than cost of UUIDS, but more than of that idx approach.

Events to the rescue?

Should not bake a server into a lofi software as a mean to sync. It needs to outlive the server.

URLs as collaboration sites been found handy.

They could be treated as "compilation sites" on a subject.

Where each user could have their own compiled view.

I.e., they are IDs of subjects. Note: ID not= content. Content is user-specific. A personal compilation / view on it.

Would it be valuable to have it generic?

Same time-travel interface for all the apps.

The mentioned "one user sets state on a task to one state and another to another" happened. As mentioned, it's not clear how to resolve. So they did encounter merge conflicts. I guess these conflicts are not app-specific and conflict resolution can be implemented in a generic way as well. Such as present users with choice which delta to adopt.

CouchDB is a meh local-first backend (storage).

Rather "thick-client local-first apps". As "thick-client" on it's own does not imply local-first, there may be a server.

Web apps can be thick clients.

Optionally they can be loaded gradually. E.g., with granularity down to components, as shown by ReactJS.

Having loaded the entirety - they can potentially work offline.

Making web app and its components content-addressable would allow to load them with no regard to location / some authoritative service.

Local Storage is not a good solution for persistence.

Sending git diffs as text over emails or other medius is the way it's been meant to use, if I'm not mistaken.

I.e., software engineers may be best keen to adopt lofi concepts.

Because it captures snapshots and not deltas.

There is no "shared master branch" in git. Subsequently, no authority that decides what's in it. Each git user is free to adopt any changes they see fit.

In an event when the sync service is down and you lose local copy - you won't be able to restore.

For this case it's better to have multiple sync options. Such as your other devices and incentivized third-parties.

Whereas it is the opposite in reality. Devices are the primary sites of intent they issue. And server is merely an aggregation site.

Given email is signed.

Git alone does not dictate how one transfers stuff.

Loosing a PHD paper, especially after it has been published and some other papers already referred to it / based their reasoning on top of it, would be a serious hit to humanity's knowledge. Sadly, this is the reality today, may happen.

Would be nice for lofi software to make it as seemless as replicating across chosen parties automatically.

E.g., in your account you linked your devices, and chosen them as replication sites. In addition you chosen a third-party, e.g., Web3Storage.

So you can use apps and rest worry-free about persistence of your data.

Even better if software uses known data model, such as RDF, and so you're not locked onto the tool.

Perhaps even better to capture your intent as events and have data models derived out of it. This way you're not even locked at e.g., RDF ecosystem.

I.e., don't rely on third-party as a medium to express yourself. Otherwise they're in control what you can express.

E.g., Twitter/X, Google Docs and their bans.

I have dread in my head every time I use cloud service that there is an issue about to happen. There will be a data breach, data loss, service becoming unavailable (e.g., they don't like you anymor, e.g., Github can block you from your private repos at their will), it's just a matter of time.

So I need to get my data out, back it up, if service been kind to allow for that. But that's a burden. It's a hidden cost you learn to recognize over time. May not be apparent from the start to everybody.

This needs explanation.

This stems from the design that there is a mutable place and some authority over it. E.g., a Google Doc, Wikipedia page.

Would be nicer to embrace people as primary sites of their intent. And allow to compose them. This way a person who would previously need to request changes to a doc, would simply have a kind of forked doc locally, where he would make the change. And that delta may be shared with the original doc's authors, who may accept or reject it. With no regard to their decision, the forked version stays as intented, with the delta.

I.e., docs are sites that aggregated some deltas. Have a site per person. Allow sites to exhcange deltas. This allows for having personal views on a subject.

Akin to how it's done in Git. If only it tracked deltas and they can be arbitrary.

I.e., NextGraph gets it pretty damm right.

Also RhizomeDB is this spirit.

For the cases when you do wish to send op to a remote party you'd still need a spinner. Given you embrace distributed compute.

Local-first has most responsive UX due to operations being performed locally, as opposed to sending them to the server.

Optimistic UI / Optimistic Updates may actually fail at the source being updated (suprise-suprise, the word "optimistic" is in the definition).

This breaks down the original intent transferMoney(Alice -> Bob) into multiple one. Thus we don't have atomicity, as shown in the paper.

Breaking down seems to be just one approach of how such events can be handled by OLEP though. An implementation detail.

It seems possible to achieve atomicity and isolation for such events, as described here.

We can treat partitions as aggregates of events.

Given there is Alice and Bob, and Alice transfers Bob money.

Then we have 3 partitions, that aggregate their respective events.

Event transferMoney(Alice -> Bob) would end up in all three partitions: Alice, Bob, Alice+Bob.

Event-processing logic may be different across users.

Bidirectional lenses as a way to integrate different data models.

Event-based systems allow for divergent views as first-class citizens.

Users are empowered to create composed views out of events of their choice.

I.e., collaboration as composition.

I.e., divergent views as first-class citizens.

I.e., DB-first approach does not have divergent view as first-class citizen.

time warp as solution for eventually consistent derived state out of events.

Alternative solution is to keep snapshots.

These two solutions can complement each other.

There are two culprits here: 1. Original intent (transfer from Alice to Bob) has been split into different intents (withdraw from Alice, receive to Bob)

I.e., there is no atomicity at the level of original intent, and subsequently there is no isolation.

1. Reads are executed on derived views (DBs) that are stale.

I.e., there is no consistency.

Instead we can have 1 event that describes the original intent. It can be complemented by withdrawal approval and receiving approval. This augmented event, in form of (approvedReception (approvedWithdrawal (transaction Alice->Bob)) can be replicated across the corresponding source account and destination account logs. This way we have holistic view on what happens. This augmented event can be replicated across source account and destination account. Leading to an eventually consistent states there. Since we have requirement on atomicity of writes this event belongs in Alice+Bob log. Where each event relating to both Alice and Bob end up. Alice log and Bob log depend on Alice+Bob log. Thus ensuring that Alice and Bob are consistent with regard to Alice+Bob transactions.

To cater for 2), we need to make sure that reads happen on top of the latest log entry. We can represent read as an event that depend on the latest log event. Thus, it'll be processed on DB state as of that dependent event.

Event logs allow for gradual processing of events.

Event logs represent deltas. Whereas DB's are snapshots. Deltas may be useful in order to get insight about intentions.

DB-first approach makes harder to reconcile happened events.

Only-once semantics for side-effects by linking side-effects to a checkpoint. Thus we have a kind of a commit with side-effects as of some checkpoint. They are processed only then. And having checkpoint guarantees that it'll be picked from this state, and so side-effects won't be issued twice.

This is not the same as idempotence of side-effects. It merely guarantees that side-effects is expressed only once.

It relies that event processing won't replay events before a checkpoint. This is not the case for all architectures. Some may use time-warp technique. Some may replay from the start.

Idempotency of side-effects as a solution for multiple invocation of the same side-effect (intent).

A solution is to have events idempotent.

E.g., to have events describe intent, and be content-addressable.

Then, the same intent = the same content-based id = noop by others that already received it.

Or use ID for a node in causally aware DAG as its hash.

why so?

This is akin to specifying "validTo". However, why remove "no more valid" commits? The can be of use for time-travelling queries? E.g., "give me the state as of that validTime". And performing such queries at time when something's expired could omit/filter it out.

those, that are not used in other branches

Huh, we're losing authorship this way. And commit deduplication.

why not have a removeAccess kind of commit?

Which would allow to have management of authorized parties without the need for creating a new branch.

how so?

Nice

We may end up in scenario, where a SPARQL tx that generated commits acrsoss multiple repos is only partially valid. In one repo it's commit is valid, in another it's consider invalid. Leaving us in a half-horse-half-zebra state.

commitAckDelay?

Transmitting an event twice is a noop when we have causal deps on events. Is this purely for optimization purpose?

Why have it if each commit has it's dependencies?

Why have secret? Is public key not enough to uniquely ID a repo?

So the brokers are not per pub/sub / repo, but per user. They are a contact point / API / gateway for that user.

These brokes take on two responsibilities: 1) overall network health 2) store-and-forward for specific overlay

They'd need to be incentivized. Stakeholder of responsibilities differ. 1) stakeholders are everybody 2) stakeholders are that specific overlay's members

How this incentive's done? Can IPFS services be used for 2)? Such as Web3Storage for store.

Since it's content-addressed, can peers agree on not keeping / pinning such content?

e.g., auth as DID that have public keys on it

CRDTs at the level of compute-as-data especially interesting imo

Still, a third-party can be authorized with access to data and asked to perform a query on behalf of user.

Semantic Web PubSub on top of libp2p?

Hmm, it seems that the proposed algorithm may terminate prior to reaching n, having found the latest dependency.

Additionally, algorithm can be restructured to complete in one pass, as "go through the log until you have found all latest deps". Then algorithm will have time complexity up to O(n). If I'm not mistaken.

As an alternative, perhaps keeping indexes per each variable may provide interesting tradeoff of time for space. UPD: this technique is described in 3.3.1.

It seems this can also be delayed up to read request. Since dependencies are needed to perform computation, and computation is only needed for read.

Could instead store the last AST and have that AST point out to dependent ASTs, making one AST DAG. Content-addressing of ASTs seems nice too

SQL may not be that familiar for web devs.

GraphQL and dot.notation is what they're used to.

Have authority to sign / process updates.

I.e., there's an authority, e.g., a shop, and it would need to process requests.

What the architecture can do is to abstract from URLs/exact endpoints, having ID of the authority instead, and abstract away transport layer, i.e., nodes in network talk with each other and we don't care how, all we care is expressing intents in data and they get passed around somehow.

Creating Invocation in order to delegate execution?

Good points.

couples produces with consumer. pubsub would be a simpler approach

Receipt, perhaps?

Task, perhaps

Have it as part of Workflow, signing over its fields? As in UCAN and Invocation spec

have REQUIRED decisionTime instead?

Perhaps an alternative strategy is to authorize side-effectful resources with "only once" restrictions?

E.g., issue UCAN that limits capability to 1 invocation.

E.g., one tweet.

It can be freely delegated by executor further, but only one invocation will be possible.

Decouple effect from pure compute? Make it "await" that compute.

ok != handle(error)

Memoization: ``` let allUCANs = findAllUCANs(UCANs, UCANRevocations) // a solution of UCANs that allows for op let opUCANs = findOpUCANs(op, allUCANs) let whetherWithinTimeBounds = withinTimeBounds?(opUCANs, now)

let whetherStillCan = stillCan?(opUCANs, opUCANRevokations, whetherWithinTimeBounds) // memoized // becomes false when revokations arrive or time bounds exceeded ```

att represents attenuation / restriction / narrowing down.

Perhaps absence of attenutaion (att field) is a way to represent "nothing's restricted".

Even if BGP evaluation engine is to cache results, merging low-selectivity BGP, b1, would incur costs of joining it with the merged-in nodes, b2 and b3. Which is one merge more than in the original BE-tree.

Shouldn't these be intersecting / common bindings?

I.e., for each common binding, they should be equivalent.

I.e.,

Ω1 |><| Ω2 = {μ1 ∪ μ2 | for each common variable Vcommon, u1(Vcommon) ~ u2(Vcommon)}

meant 2, I guess

meant 2, I guess

But we need tp2 >< tp3.

This example rewrite violates that, as optional tp2 will be added on top even if it doesn't >< with tp3.

By lifting optionals to the upper level this example of ((Pa ]>< Pb) >< (Pc ]>< Pd)) ]>< (Pe ]>< Pf) could be transformed into: ((Pa >< Pc) >< (Pa ]>< Pb) >< (Pc ]>< Pd)) ]>< (Pe ]>< Pf) in prefix notation with multiple args to functions, looks: (]>< (>< Pa Pc) Pb Pd (]>< Pe Pf))

]>< is kinda "enhancing".

I.e., can be evaluated on top of ><.

And so it can be lifted to the upper layer.

E.g., tp1 ]>< (tp2 >< tp3) = tp1 >< ((tp1 ]>< tp2) >< (tp1 ]>< tp2))

E.g., (tp1 ]>< tpo1) >< (tp2 ]>< tpo2) = ((tp1 >< tp2) ]>< tpo1) >< ((tp1 >< tp2) ]>< tpo2)

Or, if we allow joints to be a function of many arguments, in prefix notation, then: (]>< tp1 tpo1 tpo2) (]>< (>< tp1 tp2) tpo1 tpo2)

Overall, we can built a plan where non-optionals are evaluated first and then enhanced by optionals. And it makes sense to do so, it's the least computation-expensive strategy.

I.e., tp1 ]>< (tp2 >< tp3) not= (tp1 ]>< tp2) >< tp3 This shows that ]>< is not associative.

To show that it's not commutative, tp1 ]>< (tp2 >< tp3) not= (tp2 >< tp3) ]>< tp1

Also, ]>< is not distributive over ><.

E.g.,

tp1 ]>< (tp2 >< tp3) not= (tp1 ]>< tp2) >< (tp1 ]>< tp2)

Also, >< is not distributive over ]><.

E.g., tp1 >< (tp2 ]>< tp3) not= (tp1 >< tp2) ]>< (tp1 >< tp2)

Optional is meant to only accrete solution with values, never restrict a match for a solution.

Optional is meant to only accrete solution with values, never restrict a match for a solution.

Can also be used with multiple variables.

This, and BIND, could be expressed as CONSTRUCT, allowing for uniform representation of how data's stored - as triples.

E.g., sparql PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX ns: <http://example.org/ns#> SELECT ?title ?discountedPrice WHERE { ?x ns:discountedPrice ?discountedPrice} CONSTRUCT { ?x ns:discountedPrice (?p*(1-?discount)) } WHERE { ?x ns:price ?p . ?x dc:title ?title . ?x ns:discount ?discount }

I.e., clojure (-> graph match-product-with-discounts derive-discounted-price (select-keys [:title :discountedPrice]))

This can be expressed as BIND at the level of query, sparing the need to introduce another special bind at the level of SELECT. Although SELECT may work on GROUPped solutions,

CONSTRUCT returns a graph, perhaps it would be of value to be able further feed it into queries, perhaps as GRAPH ?constructedGraph {query}

What's value of HAVING over writing it as FILTERing of a subquery?

There won't be duplicate values, yet we wrap with a multiset

Here, for ?s that are to be removed, they still will get LeftJoined with the optional. Seems like a redundant work. Perhaps filter first and then add optional?

From what I understand, OPTIONAL would behave like that only when appearing preceeding to non-optional clause. When it appears after a non-optional clause, it may only accrete values, but it would not restrict.

It would be possible to not block on updates if they were to captured with tx time. Then notifications would be able to grab the delta at tx time and do notification detection in parallel to coming updates.

If we are to have UCANs as delta restrictions, then this behaviour would be expressed automatically - all capabilities of UCANs in proofs would be delegated as is if no further restrcitions are specified.

Perhaps delegation arrows could be reverse to denote that they include / reference

Also a separate prf field would be of use to show for tracking delegation

Also arrows between capabilities are misleading, capabilities are not references

", that the issuer is authorized to"?

Is there value in having "*", perhaps instead we could make ucan-selector optional?

Not clear what's in it, perhaps annotate that it's a UCAN or substitute with a human-readable hash "bafy...UCAN"?

"Amplification by adding new caveat"?

"caveat"?

"Attenuates"?

"Amplification"?

This is contrary to the intuition behind caveats - they are restrictions, if no restrictions set - allow all.

"and" seems useful to have.

E.g., in the example above I'd read it as "and", actually json "mailto:username@example.com": { "msg/send": [{}], // Proof is (correctly) broader than claimed "msg/receive": [ { "max_count": 5, "templates": [ "newsletter", "marketing" ] } ] },

Could be unified with 1., having it as

A strict subset (attenuation) of the capability authorities from the prf field

"Operation"? The way it's named in incovation spec.

"Ability" or "Capability"?

"Abilities"?

What's value in having amplification?

Such composed tokens may become partially invalid if one of the proofs becomes revoked.

E.g., composing write access to / and /photos/ into / And having / proof become invalid would prevent access to /photos/, as it's been merged. Keeping them separately would insure more invalidation-resilient token. Although that is a point towards not merging rather than composition.

Also, composition may accidentally attenuate, as merged / access inherits timeframe of /, whereas timeframe of /photos/ could have been larger.

Also, due to difference in caveats merging by ability with no regard to caveats may lead to / access attenuate less-caveaty /photos/ access. We could try to determine if / caveats are more ampe than /photos/ caveats and merge only then, but that may be error-prone and complex to do.

Also proofs most likely will have different valid timeframes, so the composed token will be partially invalid at some time.

Seems redundant. What's value in having an empty map vs absent key?

"to"?

"identify with multiple keys instead of a specific identifier"?

This delegated capabilities did not attenuate

Could be additionally clarified, that delegation validFrom + validTo timerange should be contained in the timerange of its Proof UCAN.

exp may be mistakenly thought of "expires in some time" rather than "expires at time".

Perhaps use "validFromTime" vft and "validToTime" vtt or smth?

Why not optional, as with nbf?

.

bob?

Should it include "cause" field, pointing to updateDnsInvocation?

Should we reverse arrows to indicate that tasks depend / contain?

What's the value from doing so? Could Executor not run such task at all?

Can we represent Effect as Task?

In order to make spec more compact / generic.

of what?

"sync" and "async"

How is it different from Receipt?

Can it reuse await/ok approach?

updateDnsInstruction?

sendEmailInstruction?

createBlogPostInstruction?

Should it be in the same domain model as other byte values? E.g., [200 "giga" "bytes"].

Would it be useful for "memory" (and other byte value fields) to support number value in bytes?

Would it be useful for "timeout" to support number value in milliseconds.

It's a rather standard approach, may be easy to use.

Akin to reduce(previousDB, tx) => currentDB

^Q can be generalized as yet another T, denotade sa ^T (^ hints that it this "live" T may be applied on top of other Ts / maintains a "live" view).

This gives the ability for a ^T to depend on other ^Ts.

So, for each ^T in Ts, ^T(I(Ts)) = ^T(DB).

Additionally, DB is a snapshot. Perhaps ^T(DB) better denoted as ^T(Ts).

Thus the relation can be written as

ΔV = D(^T(Ts)

Additionally, D is akin to Δ, denoting it as such we end up with

ΔV = Δ^T(Ts), for each ^T in Ts.

And since Ts are versioned, ^T(TsN) implicitly has access to ^T(TsN-1).

I.e., TsN contains ^T(TsN-1), for each ^T.

Which allows ^T to be incrementally computed over it's previous value.

^T(^T(TsN-1), TN)

^T has function signature akin to that of reduce, i.e., ^T(accumulator, sequence element)

Classes / onthologies are not a core feature of the language.

It's how we have RDF and OWS - they're separate.

Classes can be build on top of pure functions and data - these two are the core, nothing else.

Perhaps even functions can be eliminated from the core. Function is a template of some computation. It can be baked-in into the program. Since names are user-level feature.

So we end up with data and ops on it as core, and some flow control primitives (perhaps or and and is enough). The rest can be built on top. As to what data to provide, multisets seem to be the most universal data structure / less restrictive, out of which more special data structures can be derived. And with advent of SSDs we are not limited by performance to sequential reads, so perhaps it'll be not all-to-crazy to switch to multisets as basic structural block of programs from lists.

Naming system is not the core part of a language.

Naming system serves two purposes:

1. Create structure of a program

2. Give a user-friendly interface

You don't need 2. in core of your language. How data (your program) is displayed should be up to the end-user (programmer). If he wants to see it as text, formatted as a LISP - his choise, if he wants to see it as text in a Java-like style - ok, Haskel-like - sure, visual - no prob.

Having languages as data allows just that. It helps us get rid of accidental complexity from managing a syntax-heavy bag of text files (and having compilers). E.g., how Unison lang have AST as data structure and text-based interface to tweak it.

Having code as data would also make run-time tweaking more easier, bringing us closer to the promise of LISP.

And also all the rest of neat features on top of content-addressing of code, that are now waaay easier to implement, such as incremental compilation, distributed compute, caching.

Have names as user-level feature, their personal dictionaries. Some will call reducing function reduce, some fold, some foldr, some will represent it as a triangle (for visual code management).

In no part is a core feature for a language.

The mainstream OOP is complex and has many responsibilities.

OOP as envisioned by it's creator is actor model - state management (state + managing actor) paired with linking actors together - a complex approach. Can be broken down to it's primitives. And OOP can be constructed out of them, if so desired, but not at the core level.

A good reference of language decomplection is Clojure.

Treating single values as a special case of multiple values is generally more performant.

IO is not the core of the language. It's more of an utility layer that allow the language to speak to the outside world.