Also true. I would still like it if formulas could be copy pasted (so CurrentValues of different colors wouldn’t be enough). But yeah, a PreviousValue autocomplete could be nice
For those following along here we just released a new feature which will help with this problem. You can read more about it here:
Rarely if ever has
been met with the feature I begged for less that 24 hours later. Thank you thank you thank you
Update on this:
I was wrong, the equivalent formula for this using
List(1, 2, 3, 4).FormulaMap(CurrentValue.WithName(num, List("a", "b", "c", "d").FormulaMap(CurrentValue.WithName(abcd, List("w", "x", "y", "z").FormulaMap(CurrentValue.WithName(wxyz, Concatenate(num, abcd, wxyz) )) )) ))
To generate the desired output
You have to use this formula, which is the zip of the list:
List(1, 2, 3, 4).WithName(nums, nums.FormulaMap(CurrentValue.WithName(index, List("a", "b", "c", "d").WithName(abcd, List("w", "x", "y", "z").WithName(wxyz, Concatenate(nums.Nth(index), abcd.Nth(index), wxyz.Nth(index)) ) ) ) )).BulletedList()
Bingo. That is the way to do it.
After reviewing the solution that was put into place. The solution I have quoted seems MUCH cleaner.
I’m guessing the reason this wasn’t selected is because the scope of the namespace isn’t clear?
Nevermind thought about this more and that doesn’t explain it. Why wasn’t:
List(1, 2, 3).FormulaMap(CurrentValue as num, ...)
Perhaps this had something to do with increased parser complexity?
WithName approach was chosen because it aligned well with the overall functional approach throughout the rest of the Coda formula language. All other options, while heavily considered and debated, introduced new syntax, which was undesirable.
It works fine, so no complaints, but I do find myself wishing for more programmatic structures as I move forward. Coda still holds a very important place for me as a powerful note taking tool and ‘light’ database.
I get that, but we also have:
<, >, =, AND, OR
Instead of only pure functional equivalents:
LessThan(), GreaterThan(), And(), Or()
AS would have been (and still would be) a welcome addition
<, >, =, AND, OR it really doesn’t suffer from issues of context nor namespace (and parentheses can solve those remaining ambiguities)
All these are binary operators that return one value that they can be interchangeably substituted with. Both
2 > 3,
Today() > RoundDown(Date(2000, 1, 1), 5) and just
false. This is the fundamental principle of Coda expressions: each
value. Idempotent and no side effects.
X as Y return?
It wouldn’t return anything, it would create a reassignment of
My point is not that this is equivalent to binary operators, but that there is precedent for making exceptions to the functional norm.
There’s no precedent so far.
+ - / * = < > != <= >= AND OR
all work like this:
expr OP expr →
. (dot operator aka dereference) works like
In traditional programming languages you have assignment operators, yes. You can have expressions like
x = expr to assign the value of the expression into variable
x. But then again, in traditional programming languages you write your code as a sequence of expressions:
expr1; expr2; ... exprN
In Coda you cannot do that because ultimately you’re calculating just one value. So your whole formula can only be one
expr (possibly containing many sub-expressions following the substitution rule of
expr is equivalent to value). Remaking the formula language to support sequences of expressions would mean departing from its current state completely.
You’d say there are actions, but actions are a different thing and more in line with traditional programming. Actions do have side effects and occasionally return a value within their futures.
No one said the functional norm would mean no operators. Even Excel has ±/* etc.
I’m just saying that the introduction of
AS would be a huge exception in what’s a very elegant and logical system at the moment.
Coda doesn’t have a lot of operators: no tertiary operator
?:, no unary operators like
!, no right-associative operators like
expr1 expr2 ... exprN
and the resulting
- Why couldn’t
x AS ybe syntactic sugar for
WithName(x, y, ...whose scope implicitly encloses the entire subsequent formula?
- Why isn’t dereferencing much like name reassignment? Instead of looking for the field in the object you’re looking up the field in a local namespace object.