<triallax>
if the limitation isn't going away anytime soon would be nice if we had a better error message
<sharkdp>
true
<achin>
i'm not sure how to prevent this. i doubt numbat could reliably prevent infinitly recursive calls. but i really cared about this in the bot, i would probably run numbat in wasmtime configured with fuel https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.consume_fuel
<triallax>
that's impossible isn't it
<triallax>
actually is numbat turing complete
<triallax>
in its current form
<triallax>
i guess since it supports recursion yes?
<sharkdp>
consume_fuel, I like it
<sharkdp>
I would be surprised if it weren't turing complete :-). Recursion is not enough, you also need a "tape". But since we have strings...
<sharkdp>
Or probably you can also use the binary representation in numbers as your (not so infinite) tape
<triallax>
i only have a general understanding of turing completeness unfortunately, i haven't been taught anything about it yet
<triallax>
actually it's pretty crazy that the whole first year of comp scpi never touched on this
<triallax>
but yeah of course we'd need a tape
<achin>
i'm sure you could use that fib example (which is guarenteed to complete in finite time), but give it a sufficiently large input so that it will take "too long" for your given use case
<achin>
i dunno if it would be expensive to count how often we recurse and put a [configurable] limit on that
<sharkdp>
For the IRC bot, that would be useful. But otherwise.. why should we?
<achin>
not sure
<achin>
having a "RunTooLong" runtime error might be a better user experience than having to ctrl-c a CLI numbat process (thus losing your context)
<achin>
but maybe no one actually runs into this problem in the real world
<triallax>
or otherwise it could also be nice to terminate the evaluation of an expression
<triallax>
but that might be a bit tricky to do
<sharkdp>
as for "what happens if you call forever(0) in the CLI": it will not cause a (Rust) stack overflow. Insect would have done that. But the bytecode VM is not a recursive interpreter. What happens instead is that we grow the (Numbat) stack indefinitely ... because we don't have tail call optimization. So it eventually will be killed by the OS when it runs OOM.
<sharkdp>
I mean.. something like Python does ("maximum recursion depth exceeded") might make sense, yes.
<achin>
!nb fn fib(n: Scalar) -> Scalar = if n <= 2 then 1 else fib(n - 2) + fib(n - 1)
<achin>
at the moment, error handling is very basic, it just takes the Display representation of the error returned by interpret_with_settings()
<achin>
i'm also not yet 100% sold on having the bot echo the input statements before the result, but at the moment i think i like it
<sharkdp>
I added a detailed description to https://github.com/sharkdp/numbat/pull/432. Maybe we can find a useful intermediate state that we can merge before tackling the deeper type-theoretic issues.
<sharkdp>
I guess we would need to implement most functions via the FFI for now.
sharkdp has quit [Remote host closed the connection]
Charbot9000 has quit [Remote host closed the connection]
Charbot9000 has joined #numbat
<achin>
sharkdp: i updated the bot to use your latest lists PR
<achin>
!nb head([1 foot, 2 inches])
<Charbot9000>
head([1 foot, 2 inch]) = 1 ft [Length]
<achin>
!nb fn sum<T>(list: List<T>) -> T = if len(list) == 1 then head(list) else head(list) + sum(tail(list))
<Charbot9000>
fn sum<T>(list: List<T>) -> T = if (len(list) == 1) then head(list) else (head(list) + sum(tail(list)))