Thanks a lot for making me aware of that implementation by José I. Romero!
I have to give it a try (when I find some time)
And thanks to Alex for explaining the matter re. PicoLisp and Ctrl-D.
> Have you tried this:
> On Tue, Dec 31, 2013 at 10:02 AM, Alexander Burger
>> Hi Jon,
>> > server, and I have discovered that PicoLisp (at least the 32-bit),
>> > behaves a little different from other "applications" (incl. bash and
>> > ersatz/pil).
>> > ...
>> > websocketd --port=8080 -devconsole pil
>> > (You get cleaner results back from PicoLisp if you don't add the "+"
>> > after "pil".)
>> > ...
>> > ersatz/pil and other "applications", is that if you click the
>> > disconnect button, then pil32 is not terminated. On my Mac it
>> > instead starts using close to 100% CPU, and I have to kill it
>> > manually. If I, instead of clicking disconnect, type "(bye)", then
>> > PicoLisp terminates and I get a 'disconnect'.
>> I haven't tried exactly this example, but I think I can explain the
>> The runtime behavior of PicoLisp differs from other applications in that
>> it evaluates all command-line arguments, and then goes into an infinite
>> loop (REPL). This means specifically that (bye) must be called
>> eventually. In debug mode, the REPL line editor takes care of that, by
>> calling (bye) when Ctrl-D is hit.
>> Perhaps it is a bug that EOF on STDIN is not handled more gracefully,
>> and I'm not sure at the moment what it would involve.
>> "Barebone" stdio-programs like bash, ersatzLisp, but also e.g.
>> miniPicoLisp terminate despite of that, because they don't set up a
>> special handler for the console.
>> In any case, scripts like yours
>> > #!/usr/bin/picolisp /usr/lib/picolisp/lib.l
>> > (load "@lib/misc.l")
>> > (in NIL
>> > (use (Exe Res)
>> > (until (eof)
>> > (setq Exe (read))
>> > (prin "-> ")
>> > (println
>> > (setq Res
>> > (let @ Res
>> > (eval Exe) ) ) )
>> > (flush) ) ) )
>> should always call (bye) in the end (i.e. after 'until' or the enclosing
>> 'in' terminated).
>> > Something else is that output that goes to STDERR, does not show up
>> > in the browser (it ends up in the websocketd log), and I guess that
>> > is why I don't see any response if I type something like "(foo)",
>> > where 'foo' is undefined. Can output to STDERR in an easy way be
>> > redirected to STDOUT in a REPL script?
>> Yes, this should be doable with (err NIL ...)
>> ?? Alex