> * Don Cohen <qba-fbheprsbetr-k2012@...> [2012-07-08 01:51:34 -0700]:
>
> Sam Steingold writes:
> > > * Don Cohen <qba-fbheprsbetr-kkmj@...> [2012-07-07 20:33:47 -0700]:
> > >
> > > Sam Steingold writes:
> > >
> > > > EXPAND-FORM produces code which will be actually executed.
> > > > since COND is implemented as a special form in clisp
> > > > (the macroexpansion is provided for standard compliance)
> > > > it is not expanded by EXPAND-FORM.
> > > This doesn't explain (EXT:EXPAND-FORM '(incf (cond (x y)))).
> >
> > why?
>
> I'd expect that to show an expansion of incf but not cond.
> Why should this "expand" the cond when (f (cond (x y))) does not?
Because INCF is a macro which can do whatever it likes with the form it
receives.
Specifically, it calls GET-SETF-EXPANSION and does its magic from there.
> > http://clisp.org/impnotes/misc-data.html
> Thanks. Also that refers to 3-1-2-1-2-2
> I thought I had seen such a thing before, but it really contradicts
> 3-1-2-1-2-1 which says that there are no other special operators.
No, it says that there is no way to define new special operators.
--
Sam Steingold (http://sds.podval.org/) on Ubuntu 12.04 (precise) X 11.0.11103000
http://www.childpsy.net/http://think-israel.orghttp://thereligionofpeace.comhttp://pmw.org.ilhttp://camera.orghttp://truepeace.orghttp://dhimmi.com
Who is General Failure and why is he reading my hard disk?

Sam Steingold writes:
> > * Don Cohen <qba-fbheprsbetr-kkmj@...> [2012-07-07 20:33:47 -0700]:
> >
> > Sam Steingold writes:
> >
> > > EXPAND-FORM produces code which will be actually executed.
> > > since COND is implemented as a special form in clisp
> > > (the macroexpansion is provided for standard compliance)
> > > it is not expanded by EXPAND-FORM.
> > This doesn't explain (EXT:EXPAND-FORM '(incf (cond (x y)))).
>
> why?
I'd expect that to show an expansion of incf but not cond.
Why should this "expand" the cond when (f (cond (x y))) does not?
> http://clisp.org/impnotes/misc-data.html
Thanks. Also that refers to 3-1-2-1-2-2
I thought I had seen such a thing before, but it really contradicts
3-1-2-1-2-1 which says that there are no other special operators.
I wish ...-1 had referred to ...-2.

> * Don Cohen <qba-fbheprsbetr-kkmj@...> [2012-07-07 20:33:47 -0700]:
>
> Sam Steingold writes:
>
> > EXPAND-FORM produces code which will be actually executed.
> > since COND is implemented as a special form in clisp
> > (the macroexpansion is provided for standard compliance)
> > it is not expanded by EXPAND-FORM.
> This doesn't explain (EXT:EXPAND-FORM '(incf (cond (x y)))).
why?
> Also, HyperSpec/Body/sec_3-1-2-1-2-1.html says that the set of special
> operators is fixed - it gives a list that doesn't contain cond.
that's why the macroexpansions are still provided.
> So if I want to implement a code walker I can't expect to to use
> expand-form to expand things into plain functions and the list of
> special operators in sec_3-1-2-1-2-1.html.
of course!
> Is there a list of the "added" special operators in clisp?
http://clisp.org/impnotes/misc-data.html
--
Sam Steingold (http://sds.podval.org/) on Ubuntu 12.04 (precise) X 11.0.11103000
http://www.childpsy.net/http://truepeace.orghttp://openvotingconsortium.orghttp://camera.orghttp://pmw.org.ilhttp://jihadwatch.orghttp://dhimmi.com
Isn't "Microsoft Works" an advertisement lie?

edgar writes:
> AFAIK there are no EVALHOOK, APPLYHOOK, *EVALHOOK* and *APPLYHOOK*
> in ANSI Common Lisp - CLtL2 predates ANSI.
This is all true and I'm not arguing that they are are required to
work by the ansi standard.
However they are in the ext package. So it's at least legitimate to
ask what they are supposed to do.
If they are supposed to do something other than what CLTL2 describes
then that should at least be documented. And perhaps even if not.

Am Sat, 7 Jul 2012 11:09:38 -0700 (PDT)
schrieb don-sourceforge-xxzw@... (Don Cohen):
>
> I see no documentation in impnotes.
> When I try the example at
> http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node180.html
> I get no tracing.
> Am I missing something?
>
AFAIK there are no EVALHOOK, APPLYHOOK, *EVALHOOK* and *APPLYHOOK*
in ANSI Common Lisp - CLtL2 predates ANSI.
- edgar
--
The author of this email does not necessarily endorse the following
advertisements, which are the sole responsibility of the advertiser:

"scarbonell@..." <scarbonell@...> writes:
> Hi,
>
> I'm trying to redirect lisp stardard-output to sockets and with the
> algorith from Pascal, works fine, but now I have got another problem
> is that stardard-input is not appearing in the java console.
>
> In lisp there are this function:
>
> (let* ((*standard-input* socket)
> (*standard-output* socket)
> (*error-output* socket)
> (*trace-output* socket)
> (*terminal-io* (make-two-way-stream *standard-input* *standard-output*))
> (*query-io* *terminal-io*)
> (*debug-io* *terminal-io*)
> ;; We make a closure to capture socket here:
> (force-output (lambda () (force-output socket))))
> (handler-case
> (let ((socket nil) ; so that we can shadow it here.
> (results (multiple-value-list (eval (read)))))
> (funcall force-output)
> (format t "~&--> ~{~S~^~% ~}~%" results)
> (format t "--FIN--")
> (funcall force-output))
> (error (err)
> (funcall force-output)
> (format t "~&ERROR: ~A~%" err)
> (funcall force-output))))
>
> and works fine to redirect standard-output to socket. It's suppose
> that standard-input is redirected to the same socket too, and in the
> lisp code, there are other function to obtain the input information
> using read-char, but ignores it.
>
> (def$method (tty-dialog-mixin :confirm) (&rest comments)
> "writes comments to dialog-stream and waits for input.
> comments are printed without slashification.
> returns :yes if *end-key* is entered and nil otherwise."
> (lexpr-$send self :notify comments)
> (format dialog-stream "~:[~;~%~] ~@? "
> (rest comments)
> (getentry type-end-to-confirm-str babylon-io-table)
> *end-key*)
> (force-output dialog-stream)
> (let ((char (read-char dialog-stream)))
> (if (eql char *end-key*)
> :yes)))
>
> I've changed dialog-stream by *standard-input*, but I obtain the same result:
>
> I enter some key but appears "EVAL: variable E has no value", it's
> like that the function in the lisp code doesn't capture the key, so
> the function doesn't work and the program is stopped. I don't know how
> to stop the execution when in lisp code appears the read-char function
> and to wait I enter some value.
When READ-CHAR is called (also thru READ, READ-LINE, etc), the clisp
process calls read(2) on the socket. If there are no bytes received,
then the operating system waits, blocking the clisp process, until some
byte is received on that socket.
So what are you doing on the other side, in the Java process? Why
aren't you sending some bytes? Also, if you use read-line, be sure to
send a newline, and if you expect an *end-key*, be sure to send it (and
flush it) from the java side.
Now there would be other, more complex ways to do it. Using
gray-streams, you could implement a method to read characters or lines
that would send a message to the java side, upon receiption of which the
java side would read a character or line from the user and send it back,
and then your gray-stream would return it as read. Thus you would have
to implement a specific protocol, an "input" server on the java side,
and a gray-stream subclass in clisp. Much more complex. But this would
allow for example to pop-up dialogs on the java side when input is
required. Also, you could deal with the *query-io* specially, gathering
all output on *query-io* to be displayed on the dialog popped-up when
reading from *query-io* and other fancy things.
But if you don't want to enter in those complexities, then just ensure
that the java side is both reading from the socket to get output from
lisp, AND writing to the socket any inut the lisp side must read.
Typically, you could have in java something like:
(loop
(when (listen *terminal-io*)
(write-line (read-line *terminal-io*) clisp-socket))
(when (listen clisp-socket)
(write-line (read-line clisp-socket) *terminal-io*)))
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Hi,
I'm trying to redirect lisp stardard-output to sockets and with the algorith from Pascal, works fine, but now I have got another problem is that stardard-input is not appearing in the java console.
In lisp there are this function:
(let* ((*standard-input* socket)
(*standard-output* socket)
(*error-output* socket)
(*trace-output* socket)
(*terminal-io* (make-two-way-stream *standard-input* *standard-output*))
(*query-io* *terminal-io*)
(*debug-io* *terminal-io*)
;; We make a closure to capture socket here:
(force-output (lambda () (force-output socket))))
(handler-case
(let ((socket nil) ; so that we can shadow it here.
(results (multiple-value-list (eval (read)))))
(funcall force-output)
(format t "~&amp;--> ~{~S~^~% ~}~%" results)
(format t "--FIN--")
(funcall force-output))
(error (err)
(funcall force-output)
(format t "~&amp;ERROR: ~A~%" err)
(funcall force-output))))
and works fine to redirect standard-output to socket. It's suppose that standard-input is redirected to the same socket too, and in the lisp code, there are other function to obtain the input information using read-char, but ignores it.
(def$method (tty-dialog-mixin :confirm) (&amp;rest comments)
"writes comments to dialog-stream and waits for input.
comments are printed without slashification.
returns :yes if *end-key* is entered and nil otherwise."
(lexpr-$send self :notify comments)
(format dialog-stream "~:[~;~%~] ~@? "
(rest comments)
(getentry type-end-to-confirm-str babylon-io-table)
*end-key*)
(force-output dialog-stream)
(let ((char (read-char dialog-stream)))
(if (eql char *end-key*)
:yes)))
I've changed dialog-stream by *standard-input*, but I obtain the same result:
I enter some key but appears "EVAL: variable E has no value", it's like that the function in the lisp code doesn't capture the key, so the function doesn't work and the program is stopped. I don't know how to stop the execution when in lisp code appears the read-char function and to wait I enter some value.
Thanks