> Java-like languages don't immediately support something like that, but Shell-like do with redirection syntax, tee, xargs.
But in Lisp you are not bound to the language syntax of Java. You can inside the language write tools to process forms. That's one of the main differences between Java and Lisp. Lisp has reader macros (to change the surface syntax of s-expressions) and macros to change the expression syntax. That would allow you to write tools to process code and results in arbitrary ways.
Multiple-values results in a REPL are handled by the variable /. That one is the list of the last values.
CL-USER 4 > (values 1 2 3)
1
2
3
CL-USER 5 > (multiple-value-bind (a b c) (values-list /) (list a b c))
(1 2 3)
But anyway, I would not write Common Lisp in a pure terminal without editing support.
Something like GNU Emacs can use tools like SLIME or has a SHELL mode. That one works fine in a terminal.
SLIME is one of the Common Lisp IDE extensions for GNU Emacs and works fine in a terminal.
Writing even the most complex code inside an GNU Emacs & SLIME terminal session is no problem at all. If I have a function call (foo a) and I want to wrap code to the front, I would just move the cursor one s-expression back and type. I'm sure that's easier with one of the other editor extensions which make editing s-expressions kind of structural.
EVEN then, many people write the actual Lisp code in an editor buffer (say GNU Emacs in a terminal connected to a Lisp process via SLIME) and send the expression for evaluation to a connected or underlying interactive Lisp sessions. The editing of s-expressions in a terminal to move forward, backward, upward, etc is really a non-issue.
Interactive read-eval-print-loops does not mean one is forced to use a terminal without editing support.
I've been using CL and SLIME for over 10 years and had no idea about special meaning of "/"... TIL.
Anyways, the problem with handler-case still stands, as well as the other aspects s.a. chunked output, tee and redirects. It's something that would have to be programmed on top of the existing stuff, which was my point originally.
But in Lisp you are not bound to the language syntax of Java. You can inside the language write tools to process forms. That's one of the main differences between Java and Lisp. Lisp has reader macros (to change the surface syntax of s-expressions) and macros to change the expression syntax. That would allow you to write tools to process code and results in arbitrary ways.
Multiple-values results in a REPL are handled by the variable /. That one is the list of the last values.
But anyway, I would not write Common Lisp in a pure terminal without editing support.Something like GNU Emacs can use tools like SLIME or has a SHELL mode. That one works fine in a terminal.
SLIME is one of the Common Lisp IDE extensions for GNU Emacs and works fine in a terminal. Writing even the most complex code inside an GNU Emacs & SLIME terminal session is no problem at all. If I have a function call (foo a) and I want to wrap code to the front, I would just move the cursor one s-expression back and type. I'm sure that's easier with one of the other editor extensions which make editing s-expressions kind of structural.
EVEN then, many people write the actual Lisp code in an editor buffer (say GNU Emacs in a terminal connected to a Lisp process via SLIME) and send the expression for evaluation to a connected or underlying interactive Lisp sessions. The editing of s-expressions in a terminal to move forward, backward, upward, etc is really a non-issue.
Interactive read-eval-print-loops does not mean one is forced to use a terminal without editing support.