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.

Would be nice to have them at run-time.

OOP is an abstraction that is useful for a very narrow amount of use-cases, giving accidental complexity to others. Personally, I'd leave it out of the core.

This moves us away from the value of LISP as a meta-language that can change itself. We have macros at compile time, and not run-time. Having them at run-time gives us power we've been originally promised by LISP philosophy. Having no run-time dynamism would not allow for this feature.

I.e., having codebase as persistent data structure, tweakable at run-time sounds powerful.

A possible approach to that is having LISP hosted, providing a simpler interface on top of established but less simple and expressive environments. E.g., the Clojure way.

This is an effort to battle the LISP Curse. Would be a great movement, as it's one of the LISPs hinderspots. (another is adoption, tried to be solved by Clojure)

That would be great. And it is. Unison Lang gives us this power. Hope for wider adoption.

Having content-addressable codebase simplifies it a ton.

Perhaps an AST can be built on top of IPVM, akin to Unison Lang, but for any WASM 40+ langs out there.

Having common data structures would be great.

Atm each language implements the same data structures on its own.

Would be nice to have them protocol-based, implementation-agnostic.

Likely, IPLD gives us the common data structures.

Been true. Fixed in Clojure. Clojure is top-tier in integration with host platforms.

That's a good point. Again, not something inherent in LISPs. Possibly due to lack of adoption and the LISP Curse.

Not an inherent trait of LISP envs. And LISPs do have multiuser envs, e.g., REPL to which you can connect multiple clients.

Environments for LISPs are simpler due to simplicity of the language they're for. For a more complex language they'd be only more complex and hence more difficult to use.

Not sure I get that

How that is a trait of non-LISP environments?

More than that, it seems LISPs give you greater introspection. E.g., because of REPL. E.g., because of macros that can sprinkle code with introspection in dev environment and be rid of it in prod env.

How is that an inherent property of LISP environments?

Surely they can be extended with all the mentioned properties.

It does require effort to implement, and with sufficient resources behind an environment it would be wise to invest there.

E.g., Emacs has great docs. Clojure ecosystem has great docs and is a joy to work in.

I'd say LISPs have greater potential user-friendliness due to simplicity of interface. Simple interface + good docs is more user-friendly than complex interface + great docs.

And you don't need that much docs in the first place for simple interface.

As well as a simple, well-designed interface can serve as documentation itself, because you can grok on it, instead of going through docs. You mostly need docs for the mindset.

This is great. It's a desirable trait. But I don't see how that is a unique value available only for Non-Lisp environments.

What's wrong with that? Files are universaly accesable on a machine (and with IPFS - across the machines), seems to be a good design for the times. Any programs can interoperate through files - a common interface.

Files are 'caches' of computations made.

Sure, it would be nice to capture computations behind it as well, although that is not practical for back in times and is not that much needed.

But nowadays IPVM does just that at a globe-scale. And, thankfully, we also have a data structures as means to communicate and not a custom text.

I don't see what's wrong with that approach. Taking it further (as IPVM does) gives a next level of simplicity and interoperability, along with immutability/persistence - a game changer.

Well, that's a shame. Composability is a valuable trait of computer programs, at user interface included. The facts that they're not composable may mean that the problem domain is not well known, so it wasn't clear what are the components. Perhaps with time it'll become clearer. This is, interestingly is a non-the-right-thing approach. UI got shiped to satisfy the need without covering all the cases (integration of UIs). A lean startup approach. E.g., Emacs starter as non-composable and now turns into composable.

What's "right" is context-dependent. For programmers the right thing will be a simple and performant and mainstream etc. language.

LISP did not check all the boxes back then. Clojure now tries to get closer to checking what a programmer may need in production, and has a broader success.

Clojure had effort in it's design to make it a simple-interface thing, and it's excellent in that. It had effort in making it easy to adopt. So it's a well-design virus. The right thing. Virality is one of the traits of the right thing, in the context of production programming.

Performance is not the only metric of "goodness" of code. Simplicity is one of.

Often performance is not the higest value for business. It is especially so when we have ever-growing powerful hardware.

LISP allows for simplicity of interface. You can iterate on making the implementation performant, if you need so, later on.

Great, don't go 100% in. Especially since those last 20% take 80% of time. But please do have a good interface design in those 50%. It is to stay.

Unix is a mono kernel. C is a fixed language, whereas LISP can be extended with macros.

Composability is a trait of a good design. I'd expect The Right Thing approach to produce composable products, and Worse Is Better approach to produce complexed ones.

It is more fun to play with simple things. They're more rewarding.

C is more simple in implementation than a LISP. It's more fun to play with it's compiler. LISP is more simpler in interface than C, it's more fun to play with it as a language. (hence the LISP Curse)

I wonder why we don't have a C Curse at the level of compiler though. Or do we?

Huge doubts there. The original interface will stay there in some way or another. And it is complex. So users will pay the cost of it from then on.

E.g., Java is OOP, it introduces functional style, but OOP stays there. Some folks would like to switch to functional, but there is pressure from legacy codebase and legacy mindset around to carry on in the same fashion.

E.g., C is still a C. C++ and other C* are not far away in simplicity of their interface.

Unix is still a text-based chatter mono kernel.

It seems hard to impossible to change the core design, so in Worse is Better it stays Worse.

Can you go far with such a design before getting down in accidental complexity from having complex abstractions?

Abstracting away is the bread and butter of programming. In order to do it efficiently you need simple abstractions - simple interface. For this task interface simplicity is way more valuable than the implementation simplicity. E.g., you may have a functional interface on top of an imprerative implementation.

C is complex, compared to LISPs.

Unix has a mono kernel and a ton of C.

Are they the crux of simplicity, which is the highest value of Worse is Better?

.

.

Although an alternative approach of processing inputs as soon as they arrive is used as well, and may provide for better experience.

E.g., as seen in CS2.

This is a fine solution to discovery of a latest known version of a log of a machine. However, using it as a primary way would mean machines need to: store log in IPFS, publish it to IPNS, others need to resolve IPNS -> IPFS (and perhaps get notified in some way to know that there's change) and fetch from IPFS - as a solution for syncing state between two machines it will be pretty costly on time and computation required. As a solution to persist local log for other's occasional offline access - seems fine.

They can be made persistent by storing a log of messages to IPFS though, as OrbitDB does

The fact that they're not persistent by default may be a plus, as persistent is cost-heavy and can be done when required rather than always

.

didn't get it, I thought MINUS acts as disjoin

.

Perhaps immutability can be provided by having domain name of URL point to an immutable value, say content-addressable RDF or content-addressable log of txes.

.

Hmm. Query store may be eventually consistent with the command store. However, the issued query returned a stale result and there is no 'eventual getting the correct result' for it.

So we may end up in an inconsistent state no prob, where there is a command that transacts stuff based on a stale query.

Capturing query dependencies of a command in the command itself will allow for re-evaluation of queries on the consistent state.

CRUD operations can be captured as events in an event log though.

That's a strange restriction. Full-message connection has its cost, and I'd imagine peers would like to minimize that by being able to set it unidirectionaly and per-topic.

.

.

Can this be captured as SPARQL FILTER instead? Then we can keep on building the query and delegate filtering to SPARQL engine.

May not-zeroing result in unintended access to previously stored in that physical layout data?

E.g., if I intentionally create fully zeroed arrays and read previous physical layout.

This will be damm handy for ECS engines. The memory layout, shown in the associated figure, organizes data in the way such engines are querying for it.

Time-restricted feeding causes fat mass reduction, according to Dr. Satchin Panda.

It may be implemented as skipping breakfast, but it should not be breakfast necessarily.

However, there are benefits found in adopting early time-restricted feeding (skipping supper), as presented in this vid.

Not sure that's the takeaway of the study

Loading phase does increase muscle creatine levels drastically and it relies on ~20g/day. So there are effects from high dosages.

That may not be correct.

According to this figure, metabolic changes that increase absorbtion begin to appear during the train. If we are to take advantage of them perhaps we'd like to have peak creatine level at that point. However, it takes about 45 minutes for blood creatine levels to peak. Thus, it may be beneficial to ingest creatine 45 minutes prior to the train.

.

To me Trusty URIs seem to have complected two concepts that make it bad at both.

These concepts are: mutable name + immutable content.

If you care about content-based addressing - then mutable name as part of it is of no value.

If you care about resolution of immutable content from a name - you're locked to the domain name service. Whereas there may be many parties online that have the content you want to get and it could have been resolved from them.

To me it seems IPNS got it right, decoupling the two, allowing mutable names on top of immutable content.

So you can resolve name -> content-based name, from peers.

So you can refer by content-based name.

So you can deref content-based name, from peers.

It seems by maintaining a 'blacklist' of removed entries per DMC we can both preserve the log of ops intact and remove enformation of the removed log op entry.

I'd imagine it's a MUST. Otherwise replica may receive content it just removed and happily keep on storing it. Keeping such 'blacklist' is an ellegant solution. Such lists are ever-growing however and perhaps could be trimmed in some way. E.g., after everybody who's been holding the content signed that it's been removed. Although even then nothing stops somebody from uploading the newly deleted content.

I guess another solution would be not to delete somebody's content but to depersonalize that somebody. So content stays intact, signed by that somebody, however any personal information of that somebody gets removed, leaving only their public key. That would require for personal information to be stored in one mutable place that is not content-addressed.

That is a valid concern.

Perhaps we could have them both - partial order + removal of entities.

I guess it could be achieved by having op log and have a 'remove entity by its hash' op. Logs would not preserve data for such entities. However, in order to not re-hash log entries from the 'removed' log entry onward logs could keep the hash of the removed entry (but not data).

Maybe that's the way removal's done in orbitdb.

Speaking about mutable graphs, signing ops seems to be a superior technique compared to signing entities. As when signing ops triples gets signed, giving finer granularity. So there may exist entities that are combined out of triples that are signed by different authorities. Finer profiling.

Reifying key addition to be yet another op seems like a good idea. More generally it's about managing container's meta in container's state. One great benefit from it is that we have meta-ops and ops converging.

Perhaps having determenistic order for operations would sovle that problem. Then if key revocation happens before the op with that key - the op is dropped, if after - preserved.

Akin how ops are ordered in ipfs-log.

That requires key revokation to be reified - to be a plain op log entry.

Also it's mutable - server authorities have moderation powers.

Archetypes seems to be a kind of index. However, for the example given that index does not get used for its purpose. It seems a more fit solution would be to keep an index of entities per a set of components that your code actually filters by. E.g., such sets would come from Systems

We may remove it, as this reference was meant for internal use

We can rephrase it as: "Benefits from using Open Collective with Carbon Units:"

To be more professional we can write it in a more correct way: Open Collective

We can replace it with the full name: Open Collective

This can be removed.

Can be rephrased to: "Provide more services to Web3Workshop participants"

Can be rephrased to: "Close integration with ProtocolLabs project-raising ecosystem"

Can be rephrased to: "Attract customers that want Web3 applications"

.

The amount of quads in a source may be ever-growing.

Then we couldnt't count them. Is that a problem for Comunica or will it handle infinite streams fine?

I.e., stream, returned by match() keeps accreating with new values (e.g., as they are being produced by somebody).

Can't Comunica count quads as they arrive through the stream returned by match()?

Can the DELET clause be right below the above INSERT clause? So we don't need to repeat the same WHERE twice.

Also would be nice to have transactional guarantees on the whole query.

.

.

An ideal design seems to me to be the monorepo pulling from its dependent repos. It would allow for granular codebase management in repos, yet you can have discoverability via the monorepo. Also it would not complect repos with knowledge of the monorepo.

Having more aligned developers improving PL Stack is a #1 goal of EngRes in 2022.

Corps optimise for money. Giving away money for nothing in return goes against their nature.

.

An alternative domain model could be: {"a": "/a.js" "b": "/b.js" "path1": {"a": "/a1.js" {"path11": {"b": "/b11.js"}}}} This way path to a name is a 'scope'/'namespace'. Also we're spared the need of "/" in scope's names. It does look harder to parse visually than a flat model..

An alternative domain model could be: {:imports {} :scopes {:imports {} :scopes {}} This is more verbose, but more uniformal.

Bytes could be treated as an entity and resolved by a CID.

Datomic may learn at query execution time that it's a ref attribute, I'd expect it to be able to resolve a ref by it's id in such case..

.

Having modifications done to the actual entity in the db results in reactive behaviour.

E.g., you have an app called "Test App", and you display "Test App" in navbar in place of logo. Also you have a form that lets you modify it. When you modify "Test App" to "My Supa Test App" it gets updated in the navbar as you type (and across all other places). That may not be what user wants, as likely they want to set a new value. This is akin to a problem of validation, when we don't want to show "field's incorrect" when user did not touch it or is touching it.

Perhaps having "dirty" form state kept separate, and being the subject of modification would be a solution to that, having the actual used value in DB pristine. I.e., swap "dirty" and "pristine".

Also may contain inferred-input (seems it's pathom's effort to guess what's the input by analyzing fn params destructuring).

Also may contain docstring

Lists only the required attrs, optionals (via pco/?) will be listed under optionals.

Can't we pass it via --share as we did with others?

Didn't we already passed XAUTHORITY env via --share ?

Couldn't we add a symlink from /lib64 pointing to /lib of this environment?

Why not /lib instead? Seems to do exactly the same, as there is no difference if /lib comes from a stand-alonely built environment or this one, manifest is the same.

Why?

Could it be solved in a more ECS fashion by having a system that manages other systems?

That would require to have systems as entities, however.

Hmm, I'd thought an in-style to ECS solution would be to have errors as entities and error handling as a system.

But perhaps then we wouldn't have static analysis helping us by validating that all errors are being handled.

That's sick! It's always good to see things being becomplected. Looks similar to Datomic's rules and pull pattern (rules being the second query expression here in Bevy, and pull pattern being the first.

Good distinction summary of IRI URI URL URN

Can be found here: https://github.com/facebook/folly/blob/b72a70a35ada45ac286eb60028c0ecf5f6725665/folly/experimental/crypto/LtHash.h#L52

How would order be guaranteed if events can come to both streams at any time? E.g., At time1 Stream1 [] Stream2 [2]

It gets processed, outputting 2

And at time2 Stream1 [1] Stream2 []

And 1 is being outputed, resulting in [2 1] downstream.

It's nitpicking the terminology, but perhaps 'order' is not the right term, maybe 'precedence'?

Would be interesting to have a version with predicates. Idx-based slicing seems useful in a limited amount of cases.

Why not 'drop'?

Why not rx/from?

.

Won't this keep potoks alive forever? If so, it seems an app's potok pool would ever-grow, eventually dragging performance to a halt.

Why is it not defined in the let, as the others?

Why pass it as a prop and not get it from the scope?

Why this filter does not appear in sync state transformation loop?

If subs are run async, then swap!s may execute out-of-order, do they?

Would it be better to have [state event] signature in order to comply with reduce function?

.

Sounds interesting! I wonder if it puts approach of accumulative hashing of sets to use.

Persistent data structures attend this drawback by representing database as a tree and only re-hashing part of that tree that changed. E.g., how it's done in Clojure. (and some other languages I fail to recall that borrowed it)

As it mentioned in Approach 3 via merkle ttries.

Re-validating the whole database seems to be of no use, since validation is being performed already before an update is inserted into db.

I can see how having to validate every update can be wasteful if what's wanted is the final value, then the most efficient way seems to be to have that value signed and validated, as would be the case in Approach 2. But having signed updates may be desirable for some cases (e.g., for collaborative editing, as shown useful in pijul), perhaps a composed solution can be used to get the pros of the two approaches.

Authorship can be spoofed, a solution is to sign.

Excalidraw allows to disable UI theme toggle.

Excalidraw can be supplied with 'theme' argument.

Excalidraw allows to style with CSS.

Belarus sets "default tax residency" for its citizens and people allowed to stay.

Countries may want to tax you when you work on their territory.

Why to have both "source" and "selector" when "source" can be a URI of a selector?

An app better not rely on it.

Content on IPFS can share common parts.

Did not appear to me on the latest (atm) logseq dev build.

.

Fragments are not expressive enough to address an arbitrary structure.

Web Annotation allow for multiple Web Annotation Targets.

Zotero has integrations with editors.

Zoterro allows to cite.

Zoterro can take and store a snapshot of a document.

.

.

.

.

.

Shouldn't event handlers for about-to-get-rendered React components be registered prior to their render?

Why not stick to DataScript altogether?

Why not handlers?

Why is it /src/test and not /test ?

Not that it matters much, but I had an impression that that's the convention.

That comment would be cool to have as a metadata on those folders.

What's meant by that?

How does that work?

RDF* allows for nested ad-hoc reification.

Web browsers are a mess * design-wise (html, css, js, webworkers - all known to me leaves hoping for a better world) * performance wise (can't compete with a game engine) * cross-browser interoperability-wise (especially in small details, good luck getting it pixel perfect)

E.g., Tonsky's rants and his work on having a better desktop program execution environment.

Should there be? The only responsibility of a text editor is to allow to manage text. They do it best, there are many editor's up to user's taste. There is LSP that eases navigation around the text field. Editors should stay editors. I'd love so much to have one editor to edit text everywhere in my OS, be it in this comment box, somewhere else in a browser or while redacting text files.

A viz tool can be a stand-alone thing, doing it's own responsibility.

As an alternative, a graph model + labels could be serialized.

An example of that is that some people love ligatures as they make it easier to reason about code, presenting semantical symbols in stead of a sequences of chars.

Square brackets notation is used to denote a multiset.

multisets are used in membrane computing

A way to model sequences via multisets.

Sets can be modeled via multisets.

Git objects are: - blob - tree - commit

As mentioned here.

A blob is a file's content, in case of a Clojure program such content is text from a .clj or .edn or some other file.

From that, we'd still need to perform derivation of a text representation out of a graph model of a program, it seems.

.

What does it capture?

I wonder how granular does it go.

Perhaps, to some degree, due to inability of having it in the first place with non-ECS systems?

It may be useful to have nodes as an optional interface as some may find it more easy. It is not core to processing, as pointed, I'd like to have my hands on the core - data+logic.

Complexity is not taken away this way, it's hidden, It's still there, but behind a more 'easy' interface perhaps.

'event' is an easy interface.

However, it adds complexity.

The need to describe/"decide" is still there.

"event" captures data needed for a decision. "event handler" decides.

We can't escape the need of data+logic.

What I like in ECS is how data and logic is separated and how it results in a generic processing system.

Whereas with events it's.. yet another system to process data.

Why should they be? Why is it not the one system to crunch data?

And ECS just has Entities.

Also, Systems can be Entities as well, however we'd need a piece of logic to bootstrap.

And Entities are IDs, we don't need that either. Or, if we do, content-based id can be used.

I would call function "boolean?(value)" a predicate. However, the scope to which "value" is bound contains values of "true" and "false". Would this function, then, fail to classify as a predicate, but a para-operator?

Can the one argument to a function be a composite?

E.g., a dictionary/map.

If so, then function and operation seem to be equal in expressive power.

Functions can be used to construct n-ary operations.

Passing values as list embeds semantics into order/places. Place-based semantics/addressing is no good. Is there a better way?

I thought "argument" is a name for a function's input value symbol, whereas for an operation it's "operand".

Why should it be finite / bound to a particular size? I can see how an operator "+" could take any number of arguments. (+ 1 2 3 4 ...)

A function in programming languages can take an arbitrary amount of inputs, whereas usually operators are ternary at most.

I thought a bound variable will have at least an empty range. When there won't be any range at all?

What's the difference between "possible" and "authorized" variable values?

States try to fix Target's source rot.

EPA dosage optimal for antidepressant effects is <=1g/d.

There are 14 variants of serotonin receptors in the human body.

There are seven subtypes of serotonin receptors in the human body.

Absence of serotonin is related with depression.

Inhibition of GABA results in increased production and action of dopamine

beta-endorphin seems to account for majority of functional properties of endorphins

Analgesic effect of endorphins is more potent than that of morphine.

gamma-endorphin nests alpha-endorphin

beta-endorphin nests gamma-endorphin

morphine is an agonist of mu-opioid receptors

It is possible to compare equality of a map solemnly by the second predicate "for every key/value entry in one map an equal key is present and mapped to an equal value in the other".

Perhaps the definition of equality of maps can be amended to consist solemnly of the second predicate?

It is possible to compare whether two sets are equal solemnly by the second predicate "for every element in one set, an equal element is in the other".

The first predicate "sets are equal if they have the same count of elements" does not check for equality, rather is a fast check for inequality.

Perhaps the definition of equality of sets can be amended to consist solemnly of the second predicate?

\uNNNN will fit up to three bytes, whereas UTF-8 allows for up to four bytes to be encoded. Can there be \uNNNNNN?

beta-endorphin is produced by pituitary gland

beta-endorphin is produced by hypothalamus

It seems to me the only way to be able to derive any possible state of a system - is by having a snapshot of that system.

Where snapshot includes the laws on which it operates.

The proposed constrains seem to be not enough to derive the one way how snapshot2 can be derived out of snapshot1.

It seems that there may be an infinite number of ways how snapshot2 can be derived out of snapshot1.

Study suggests that our perception of time is not linear and correlates with level of dopamine.

So, perception of the universe by matter, namely humans, define properties of that universe, such as order of Nows?

What is meant by it?

What affects setting state to 'performance'?

What affects setting state to 'learning'?

Does it mean that dopamine's effect on a circuit can be both learning and performance at the same time?