Outer CurrentValue access

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

1 Like

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 WithName is:

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)

Which produces:

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,

to get:


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?

The 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

Like <, >, =, 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 return false. This is the fundamental principle of Coda expressions: each exprvalue. Idempotent and no side effects.

What would X as Y return?

It wouldn’t return anything, it would create a reassignment of CurrentValue.

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 exprvalue.

. (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:


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 ^ (power).

P.S. In JavaScript you can write


and the resulting value would be the result of the last expression. Modeling after JavaScript though is not a very bright idea (even though Coda borrows a lot from JS, it’s written in JS because there’s no other option lol)

Two qs:

  1. Why couldn’t x AS y be syntactic sugar for WithName(x, y, ... whose scope implicitly encloses the entire subsequent formula?
  2. 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.