Most people are probably voting for the general formula FR.
seems it similar to Derived Relations (Formulas)
@Filip would it be possible to join the two topics?
Just to avoid duplication, it’s less open FR 
If we take your time and this is really thought through I think a lot can be done in the future with formulas. I.e. incorporate a lot of features like roll-ups formula-first and then provide easier interfaces for users that don’t want to use formulas (but with formula architecture under the hood). I think this automatically guides some of the architectural decisions, since we can always come back to the open formula architecture and have a simple way to narrow down for more basic use cases and user requirements.
(So it might not be bad to not just copy Notions formulas as some ppl suggested, but have a strong semantic and architecture - I only use Anytype for a few days now, but I can see that many thoughts went into the architecture and it is more robust than notion architecture-wise)
I also thought again about this Formula Relations and Inline Relations topic. I think the better way would really would be the Coda way as it is simpler and allows for more use case in a more accessible way. Also this would allow TYPEing of formulas in relations (i.e. number, string, or even formatted like a $ suffix the output of the formula automatically gets converted to what the relation dictates, similar to Excel) way better and even be consistent with the interface (/ for blocks, = for formulas for example). Furthermore we wouldn’t need to really consider inline relations separately, since you can just add a formula and just reference the relation.
=this.title (maybe = is not perfect as it is often used in other contexts and it probably spawns a block-like thing like inline-latex would)
Ideally, we could use this everywhere. So, if someday we have plots, no need for the most complex interfaces, as we can use formulas to aggregate things etc. (any have a more basic interface for basic needs).
has this feature moved up the list since so many improvements have been made since 2022?
I don‘t understand why Formulas or basic features like inline sets on mobile don‘t get a lot of attention while the backlog is only talking about AI experiments and chat. I get that formulas are a massive and scary task but I don’t understand what product Anytype wants to be. I am not an opponent of gen AI or all the other things on the backlog but fixing basic things would have way higher priority to me. For example, para setups are extremely time consuming and messy currently, because phones cannot use inline sets, but they can have filters on the set pages themselves. Anytype is far from a solid or ‚complete‘ product (also reflected by version number), so going in every direction at once before focusing on the core seems like the wrong move to me. Please let me know about you opinions.
I would also add, that adding 20% of a feature like formulas would cover 80% of all usecases. Basic arithmetic and basic aggregation functions (SUM, AVG, COUNT) would cover all my use-cases for instance. I understand, that implementing it completely will be a complex and tedious task, but at least I am personally totally fine with partial (but practical) feature implementations in 0.x software.
I don’t think it’s even about the complexity of use cases, at least for me. If it’s integrated into the foundation of Anytype, meaning you can add basic functions in most areas (inside the document body, as properties, as filters etc.) - and I know this is not an easy task and must be developed in small steps - even if functions are very very basic, this would already resolve highly requested features, and would be a foundation to easily support others that get more complex. An example would be the highly requested self-referencing filters for templates or simply referencing properties (like date) in the title of a note (e.g. for daily notes). Tools like Notion build these features for a very specific audience and specific use cases and I understand that Anytype cannot focus on that. But if it’s part of functions core architecture, then a lot will be possible, even with a tiny and well-testable set of functions.
I feel like Anytype has done exactly this with the Object-oriented approach. They abstracted what really matters in tools like Notion. I fear that if functions are very late on the agenda (and therefore not a core building block for many requests), it will not be a generalized approach like this, but rather a narrow feature that works for 2 or 3 use cases. Then it’s probably still the same workload to get to a level of supporting features that other tools do, in a similar, hacky way.
How did you get to that? I couldn’t find where I could do this
You can do this in collections and queries in grid layout.
I like to use inline collections to have tables with calculations.
Ah, perfect, I had to miss that. Thank you.
Design Proposal
To fit into the Anytype model, I think that they should be represented as a new Object type “Expression”. An expression would contain code in some pure language (Haskell, etc.) that can be run in a virtual machine in the client app. This could be executed in WebAssembly. Most commonly, that expression would evaluate to a function that accepts an argument in some form. But critically, it might not. It could evaluate to some sort of data structure (string, number, list, dict).
From there, the Expression object can be pulled into other object by an object relation property. If it evaluates to a function, it would be invoked with the object to which it is assigned. That Object would proved access to that Object’s blocks and properties/relations. It would also need to be invoked with information like the current date/time. The caller would need to know what inputs are truly evaluated to know when it needs to be called again (e.g. function references the current hour, so when the hour ticks up call it again; function references some other relation, call it again if that relation changes).
Besides being a Relation, it could be embedded as a card. The function might return a data structure with what information to show in a card form. This would work in the same way an Object Link does, since again it is an Object.
And lastly, the ability to inline it directly as others have mentioned.
If Expressions are a first-class object, it allows them to be shared. For example to do image processing, an expression could be shared that can manipulate image data.
Paired with this, a Button block would be useful. The button block would have two underlying properties: the Expression object to invoke, and a Property to which to assign the result of that expression. For example, the canvas might contain two buttons, one that increments a property by one and another that decrements it by one.
Potential Use-Cases
Repeating Tasks
A function could check the current date/time, compare that to the “Next Occurrence” date, then update both. It could do this by returning a value containing the Properties that should be updated. This might need to be handled with a different kind of Object relation (an Effect?), one that is looking for properties to update. In this case, it would 1) un-check the Done property, and 2) increment the Next Occurance property based on some Frequency value.
Title From Relation
Say I have three objects: Event, Invitation, and Person. Event contains time/place properties. Person contains properties about a person (their name, contact info). Invitation contains information about the invite (was invite sent, what was the reply). Structuring that currently requires duplicating the name of the Person into the title of the Invitation. A formula could pull that in from the relation property automatically.
Word Count
An Expression could count the words (or rather, count the spaces) across the Object’s blocks, and return a word-count.
Table Formulas/Aggregation
If a link to an Expression can be inlined like inline links to other object, its text could evaluate to the results of that expression. It might be a higher-order function, and can be passed arguments, such as the row and column that it’s in.
Programatic Block
When embedding an Expression as a block, it could return a data structure that instructs what kind and what content of block it should show as.
- Expression that returns a Header block that interpolates a Property
- Expression that returns an Image block that depicts a computed QR code pointing to a URL in a Property
- Expression that produces a Table
- Expression that returns links to one or more other Objects.
File Processing
An expression could pull in a File from another Relation, parse it as a CSV, and return some result from it.
Dashboard Page
Expression Objects linked into a Page that can execute a reducer function over a query to compute summaries.
Anki-style spaced repetition, with Cards/Notes (docs)
Notes and Cards are Objects. User defines a Note containing a piece of information using various properties, like a flashcard for a word (English: bathroom; Spanish: Bano). User then creates a Card from a template, and assigns the Note to it as a Relation property. The Card Object references an Expression Object, and the Expression object pulls out the English property and displays it. The Card Object also has 4 buttons, Again/Hard/Good/Easy. Pressing each calls another Expression that computes a date/time in the future based on other Properties for “last increment” and “difficulty”, and assigns its value to a “Due” property. A Query could be used to order Notes by their Due date. The user experience would be to tap the first card in the query, tap the card memory difficulty, then click Back to see the next due card.
Inspiration
- Nix
- Angular Signals
This +1.
Naming formulas → creating a collection of formulas (that a.) can be extended and b.) build upon is quite sth which I was looking to build up via python scripts, but having that in anytype with a neat UI, wow!! wow!! much more usable then a math script and dealing with programming environments and so on)
EDIT: Simple arithmetics in terms of math would be enough to start.
No need to have complex logics already.
EDIT: I’m going to implement complex mathematical expressions via python in Obsidian for now.
/ With a plugin for codeblocks (which can make use of libraries)/dataviewjs where I can use “vault”-wide variables inside.
/ Obsidian can’t do it comftably.
If a name of a constant/variable is changed then the new name is not updated in all the formulas pointing to that constand/variable as there is no sematic relation.
← So in the end a ‘graph’ is needed for that, perfect for a key feature for Anytype that the others can’t copy if not a graph.
/ Checked the Anytype API, but an API ist just for Data. I’ll check the “extension/plugin system” if there is one.
/ For now I can use python scripts to read and write with the Anytype API, so I can have formula calculations and have the results be written into Anytype. Awsome. But of course python inside anytype for formulas would be much much more convenient and also have the autoupdate function of ‘renaming’ variables in formulas.