@Kazinator @rzeta0 No fancy inference. #Lisp knows exactly what type each datum is. Is s is a number, return that number. If sequence of length 1, then (first s) returns its only element; if of length 3, it's considered to be an infix operation, so it's reordered into (elt₂ elt₁ elt₃) and evaluated.

`cond` returns the value of the last sexpr of the first clause whose first sexpr evaluates to `t`.

@shegeley i can feel you so much #lisp langs are so superior to anything else and i have often times the feeling the tech industry doesn't realize how awesome this tech is. Everyone just follows the hype made up by google and other big tech.

but the if I swap the two cond conditions, it works...

------

(defun arith-eval (s)

(cond

( (numberp s) s)
( (equal (length s) 1) (first s))

( (equal (length s) 3) (eval (list (second s) (arith-eval (first s)) (arith-eval (third s)) )))
( t nil)

)

)

---

I can't see how ( (equal (length s) 1) (first s)) would preclude anything later?

---

2 / 2 #lisp

@Regenaxer And wow, the recursive vs iterative comparison is close! There isn't any fancy optimisation here, is there?

: (bench (apply * (range 1 10000))) T
0.075 sec
-> T
: (bench (fact 10000)) T
0.072 sec
-> T

Continuing this thread, the post-scarcity software environment can't yet do iteration, so I'm using a recursive algorithm for factorial:

(set! fact
(lambda (n)
"Compute the factorial of `n`, expected to be a natural number."
(cond ((= n 1) 1)
(t (* n (fact (- n 1)))))))

Let's look at the stack vs iterative performance of different #Lisp family languages...

Here's a gist

https://gist.github.com/simon-brooke/fcb59705950c5ad515e18fba065510ae

@Regenaxer @borkdude @vindarel Thanks! Right, so my comparable in-REPL times for iterative factorial 1000 are

#PicoLisp: (bench (apply * (range 1 1000)))
0.000 sec
#Clojure: user=> (time (apply *' (range 1 1000)))
"Elapsed time: 2.428199 msecs"
#SBCL: CL-USER[1]: (time (apply #'* (alexandria:iota 1000 :step 1)))
Evaluation took:
0.000 seconds of real time
0.000015 seconds of total run time (0.000000 user, 0.000015 system)
100.00% CPU
45,990 processor cycles
0 bytes consed

@vindarel @borkdude
@Regenaxer

It's worth pointing out that back in 1986, my Xerox 1186 boxes, running #InterLisp, took twenty-one MINUTES to compute factorial 1000.

All of these systems are, in fact, amazingly fast in their bignum performance.

@borkdude @vindarel @Regenaxer #PicoLisp doesn't have macros, by design. Its `time` function returns the time of day. So while there may be a way of timing a computation in the REPL, I've not found it yet.

#Lisp

https://software-lab.de/doc/refT.html#time

@vindarel That's true. The startup time issue is particularly harsh on #clojure, and @borkdude's #Babashka would probably do a lot better.

But (a) this is very rough timing, and (b) startup time is some sort of proxy for the compactness of the runtime system; and
(c) the thing that's still astounding me is that #PicoLisp is (sort-of) an interpreter, while all the others execute compiled code, so bloody should be faster!

@Regenaxer my jaw dropped when I hit the point in the documentation where it says 'interpreter only'. Pico-lisp is *blazingly* fast!

See (very rough) comparison to clojure, mit-scheme, sbcl:

@simon_brooke I would also say that bignums implemented internally in cells are the way to go. I did so in #PicoLisp too. #lisp

However, having bignums in vector space would cause a churn of non-standard-sized objects in vector space, which would mean much more frequent garbage collection, which has to be mark-and-sweep because unequal-sized objects, otherwise you get heap fragmentation.

So maybe I just have to put more work into debugging my cons-space bignums.

Bother, bother.

There are no perfect solutions.

#Lisp

/ continued