00:06:00
##forth
<cleobuline>
!uptim
00:06:05
##forth
<cleobuline>
!uptime
00:06:05
##forth
<LispBot860>
231h 6min 35s
00:07:44
##forth
<cleobuline>
!listcmd uptime
00:07:44
##forth
<LispBot860>
Commande !uptime : !eval (pu)
00:08:12
##forth
<cleobuline>
!listfunc pu
00:08:12
##forth
<LispBot860>
(DEFUN PU ()
00:08:13
##forth
<LispBot860>
(FORMAT NIL "~dh ~dmin ~ds" H M S)))
03:00:03
##forth
<rendar>
this is forth? it seems lisp
12:44:03
##forth
<KipIngram>
No, that's not Forth. From time to time we do talk about Lisp here.
12:45:35
##forth
<KipIngram>
When it happens to be related to the internal implementation of Lisp I find it pretty interesting - I've come to think that basic, non-optimized Lisp can be implemented in a similarly simple way to Forth. Maybe not quite AS simple, but not too bad.
17:22:44
##forth
<cleobuline>
forthBot: LOAD ini.fth
17:22:44
##forth
<forthBot>
File ini.fth with MOON loaded
17:22:50
##forth
<cleobuline>
forthBot: MOON
17:22:50
##forth
<forthBot>
Phase de la lune pour Thu December 11 2025
17:22:50
##forth
<forthBot>
🌖 Gibbeuse decroissante La lune decroit, une nuit douce vous attend ! Illumination 52%
19:22:50
##forth
<forthBot>
Environment for cleobuline inactive, freeing...
21:26:15
##forth
<[[smlckz]]>
The hardest part of a simple Lisp implementation is eval. I'll say lisps (and underlying lambda calculus) are conceptually simpler to implement than Forth. It was quite difficult for me to make sense of DOES>.. but ultimately, I'd put it this way: Lisps and Forths are duals of each other (in some vaguely yin-yang sense). Each language provides the
21:26:16
##forth
<[[smlckz]]>
next most natural implementation of the other, apart from the the one in itself.
23:36:15
##forth
<anthk_>
the zenlisp compiler basically bootstraps a huge chunk on itself
23:36:22
##forth
<anthk_>
s,compiler,interpreter
23:39:44
##forth
<anthk_>
the manual covers evertyhing
23:39:54
##forth
<anthk_>
from primitives to words