Hi Ben,
On Sat, Jun 13, 2026 at 9:59 AM Benjamin Urban <[email protected]> wrote:
>
> All,
>
> These questions have come up while I've been working on the callables for
> Calc, and I was wondering if anyone could weigh in
> 1. Is it feasible to alter the way the compiler treats jump operators? I'd
> like to eliminate the requirement that there be at least one expression that
> is always fully evaluated. I know how I would handle that in the RPN, but I
> don't know what might break if I change things at that level. This
> requirement is preventing LAMBDA expressions without any parameters, and I
> don't see any reason it should be necessary.
So I don't know if there are developers around that know the ins and
outs of how the formula compiler works to answer you about this
properly. There are a lot of us developers with general knowledge and
then we learn more about the specifics of how things actually work
when we try to fix or implement something in a certain area.
General approach applies - try it and see how far you come and what
breaks. You should quickly see if the change will be feasible or not
and if it makes the code better or not.
> 2. How much effort would it be to add syntax highlighting to the formula
> editor(s)? I would be interested in arranging for local variables to be
> colored while editing a formula.
Probably not too hard, but I never worked on that.
> 3. Is it worth the effort to be able to store a callable in a matrix? My
> thinking is that it would be, if only because, while most users would never
> try it, the one user that does and finds out that it is not possible would be
> very disappointed indeed. I'm also wondering about the extensibility of the
> type system in general, if matrices cannot accommodate more types.
So, I'm wondering what the use case would be - something like
=MAP({1,2}, { LAMBDA(a, a+1), LAMBDA(b, b*2) }, LAMBDA(x, f, f(x))) -
would be nice and this doesn't work in Excel.
> 4. I believe the type system could use an overhaul. I *think* I found all the
> places I had to account for callables, but I have no way to know for sure,
> because there are so many different ways that different data types move
> around the program. I feel that there is no need for each container class to
> have its own code to handle different types of data; that's a maintenance
> nightmare. Perhaps if they all used FormulaToken, which can already handle
> all the data types that are supported, it would be much easier to deal with.
If you have an idea then try and see if it makes things better,
reduces complexity and doesn't break things around or adds complexity.
Nobody will complain if you change things for the sake of making it
better.
> 5. Is there a unified way for an ScInterpreter to retrieve the
contents of a reference, regardless of its type? If not, I think there
should be. I wound up writing a function to deal with it, and it's
still incomplete. I'm also not sure I've handled all the possibilities
correctly.
Sounds good, if it makes things easier to work with.
> 6. I've noticed that there is no way for any information to be provided to
> the user about an error that comes up in a spreadsheet formula. All they see
> is the error code number, and the message assigned to that code. I would like
> to be able to incorporate an arbitrary message with the error object to pass
> along to the user. Of course, such a message would need to be translatable.
Good idea.
> I would be interested in taking on any/all of these tasks (over time), but I
> don't want to proceed without guidance from someone who knows the code better
> than I do. In particular, I wonder if any of these things that I see as
> unintended shortcomings are actually deliberate decisions, and, if so, I'd be
> interested in understanding the reasoning.
Well, as I said - you will probably not find someone that knows the
ins and outs of formula compiler, but at least to me what you try to
do seems reasonable. The knowledge if something is a shortcoming or
deliberate is probably lost, so just apply the tactics to make code
changes where you just don't know this fact - so by making
experiments, incremental changes, write relevant tests before you make
changes (so you know that your change doesn't break behavior). The
codebase is huge and there are just so many people around who would
know the ins and outs of every part of the codebase.
> Thank you,
> Ben
Tomaž
