Subject: [clisp-list] Re: clear-input not working from dos box?

From: [email-masked] (Don Cohen)
Date: Mon Nov 11 11:12:04 2002

> Is readline active in Don's windows CLISP?
I think not.  At least the usual mechanism for retrieving the previous
input seems not to work.  Perhaps it's a different keystroke in a dos
box, or different in windows.  This was a binary download.  
If important, tell me how to test it.

 > Does type ahead cause trouble when CLISP enters a debugger loop or
  does discarding input work fine there? That's the typical use-case for
  CLEAR-INPUT. 
I don't know.  I'm not sure how you want me to test that.
But I notice that input seems to be discarded by the top level
read-eval-print loop.  Which I suppose is the same thing.
That is, if I type
 (read)3
I don't immediately see 3 returned.  Rather it waits for input.
Then if I type 
 4
it returns 4.

Is this normal?

---

From: Sam Steingold <[email-masked]>
Date: Mon Nov 11 13:30:54 2002

> * In message <[email-masked]>
> * On the subject of "[clisp-list] Re: clear-input not working from dos box?"
> * Sent on Mon, 11 Nov 2002 10:48:09 -0800
> * Honorable [email-masked] (Don Cohen) writes:
>

CLISP REPL works like this: first we read a line and check for commands
(like "help" ":w" &c), then, if there was no command, we create a
concatenated stream out of the line and *STANDARD-INPUT* and read from
there.  I.e., the first line can contain at most 1 form.

See read_form() in debug.d.

An obvious alternative is to read from *STANDARD-INPUT* and then look up
the form read in the *KEY-BINDINGS* table.

The problem is that this way you will not be able to evaluate symbols
like "help" because they will be interpreted as commands.

Using only keywords for commands is not backward compatible and is
unlikely to happen (Bruno has explicitly vetoed it a couple of years
ago).

All this is only relevant when *STANDARD-INPUT* is interactive.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Lisp: Serious empowerment.

---

From: [email-masked] (Don Cohen)
Date: Mon Nov 11 13:43:21 2002

> there.  I.e., the first line can contain at most 1 form.
I don't see why that means the rest of the first line is discarded.
If I type
(read)3
then the concatenated stream still contains "(read)3", right?
If I do (read)(read) from that stream shouldn't I get the 3 on the
second read?

 > like "help" because they will be interpreted as commands.
Doesn't this have the same problem?
If I type help that could either be the name of a variable or a
command.  I guess for the variable I have to type something like
(progn help) or
package:help or maybe 
 help ?

I've occasionally noticed problems like
- I type abort and get another level of error cause ABORT has no value
- I type abort and get another level of error cause BORT has no value.
I never looked into them, but it sounds related.

---

From: Sam Steingold <[email-masked]>
Date: Mon Nov 11 15:30:02 2002

> * In message <[email-masked]>
> * On the subject of "Re: [clisp-list] Re: clear-input not working from dos box?"
> * Sent on Mon, 11 Nov 2002 13:33:40 -0800

your READ does not read from the concatenated stream but from
*STANDARD-INPUT*.  note that read_form() does not set *STANDARD-INPUT*.

> command.  I guess for the variable I have to type something like

indeed.
right now, a space before the variable name or a package prefix works,
but if we just READ from *STANDARD-INPUT* without the READ-LINE trick,
only PROGN will work.

> - I type abort and get another level of error cause ABORT has no value
haven't seen this for quite a while.
I thought I fixed that...

> - I type abort and get another level of error cause BORT has no value.
never seen that!

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
If you try to fail, and succeed, which have you done?