Feature request: run-time variables and functions

[EgorBron]

It would be nice if the library supported variable and math function creation during evaluation.

To keep backward compatibility, we could introduce a new function like evalExtended(String): KevalResult or something similar.

KevalResult would be a class that holds the evaluated value, or both the original expression and a callable function:

class KevalResult {
    val value: Double?
    operator fun invoke(vararg args: Double): Double { ... }
}

Given code like this:

var b = 32.0
val keval = Keval.create {
    includeDefault()
    function {
        name = "someFunc"
        implementation = { 42.0 }
    }
    function {
        name = "getB"
        implementation = { ++b }
    }
}

val kevalExpr = """
a = someFunc() * PI % getB()
b = getB()
f(x) = a*x + b
f(10)
"""

keval.evalExtended(kevalExpr).value // 341.6944...

In this example:

• We define variables a and b, which are evaluated when defined.
• We define a function f with one argument x.
• We then call f(10), which evaluates the function.

Expected behavior of evalExtended():

• If the last line is an expression, evalExtended() returns a KevalResult with a non-null value. Invoking this result returns the value.
• If the last line is a variable definition, the behavior is the same as above.
• If the last line is a function definition, the value in the returned KevalResult is null, and invoking the result will evaluate and return the function result.

What do you think about this approach?

[notKamui]

Hi, thanks for your input.

This would require a lot of development I think, basically this would make Keval an extendable functional programming language.

However, this could be part of a v2 ! Which would make it acceptable to have some breaking change.

In the vein of the ML family of languages, I think bindings should be normalized and more explicit than your examples:

let a = someFunc() * PI % getB() in
let b = getB() in
let f x = a*x + b in
f(10)

notice how a binding is let {name} {?params...} = {body} in. This kind of thing makes it clear and possible to keep one singular .eval method.

the one big massive hurdle I'm seeing right now, no matter the syntax and grammar, is recursive functions (which are necessary in functional programming if you want any kind of loops)

Ocaml defines them like this let rec {name} {?params...} = {body} in, this could be used for the syntax. But still, functionally difficult to implement. Tail-call optimization should be thought about too. Anyway, functions are massively hard.

And that goes without saying: higher order functions:

let f g x = 3 + g(x) in
let add4 x = x + 4 in
f(add4, 1) (* evaluates to 3 + (1 + 4) -> 8 *)

And furthermore, there is also conditionals, because recursion needs branching to stop

let fib n = match n with
  | 0 -> 1
  | 1 -> 1
  | _ -> fib(n-1) + fib(n-2) in

fib(10)

I would gladly accept help on this. Honestly, just for the fun of it, this is a good-bad idea.

[EgorBron]

Actually, when I came up with the idea of adding functions and variables, I didn’t really think about all the issues involved 😅. It would mean a lot of work—updating the parser, lexer, and more—while still trying to keep Keval as flexible as it is now.

I understand this idea sounds a bit silly, just a fun suggestion rather than a necessary feature. Turning Keval into a kind of full interpreter to support functions, conditions and variables would bring a big development cost, and I think most users (like me, who found Keval looking for a math expression evaluator in Kotlin Multiplatform) really only need basic math evaluation.

Actually, it turns out I’m trying to do something similar in my own work. When I came up with functions and variables, I hadn’t fully considered the challenges, and I’m running into issues myself. For example, in my JSON-based runtime Staje that I’m developing for my TTRPG companion app, I decided not to support functions directly because of these problems (like handling recursion and higher-order functions). Instead, I’m working on an extension called FlowyStaje, but just on the paper for now. That got me thinking: if I were to add functions to Keval, should we aim for high speed and performance using a smart AST optimizer or stick with a simpler implementation based on Kotlin’s runtime?

As a reference, here’s a link to a proof-of-concept interpreter I wrote as a training on writing Flowy. It works fine as a basic demo, but it implies that a truly optimized solution would require a lot more work.

---

In short, I feel this feature isn’t worth the effort unless someone has nothing else to do on the weekend. I’ll close the issue for now.