Hi,
I'm just starting out with Lispworks (Personal Edition) and am
puzzled about using READ. From the Listener window (READ)
works fine, pausing for user input. However, loading a file
created in the Editor window that contains (READ) causes the
following error to appear:
(ARRAY NIL) is an illegal type specifier.
(Same result using the menu sequence: Works -> Buffers -> Evaluate)
What gives?
Roy
"Roy Mash" <········@ci.sf.ca.us> writes:
> Hi,
> I'm just starting out with Lispworks (Personal Edition) and am
> puzzled about using READ. From the Listener window (READ)
> works fine, pausing for user input. However, loading a file
> created in the Editor window that contains (READ) causes the
> following error to appear:
> (ARRAY NIL) is an illegal type specifier.
> (Same result using the menu sequence: Works -> Buffers -> Evaluate)
>
> What gives?
Who knows what stream it is reading from. LOAD does not guarantee
to work by binding *STANDARD-INPUT*. If you are calling (read) with
no arguments, you had better (a) know what *standard-input* is and
(b) not be involving functions that are allowed to but not required
to intervene between the point of your knowledge and the point of the
call.
You might be reading off of the user interactive stream, or you might
be reading off of the load stream, or you might be reading off of lisp
system startup stream, or something else. It's just not defined. If
you're reading off of the load stream, you may be consuming a form you
expect LOAD to execute, and so only half your file may be executing
and the other half may be getting consumed as data. This could lead
to weird effects.
I didn't test LispWorks to see if it does one or the other of these.
What it does is really irrelevant. They could change it tomorrow.
What's relevant is that what you are doing is not well-defined and you
should not expect any predictable effect from it.
Kent,
> If you are calling (read) with > no arguments, you had better
> (a) know what *standard-input* is
From the Listener Window *standard-input* evaluates as:
#<EDITOR::RUBBER-STREAM #<EDITOR:BUFFER CAPI interactive-pane 2>>
From the Editor Window it evaluates as:
#<Concatenated Stream, Streams = ()>
Perhaps, in order to get user input into a program in Lispworks I need to
create an input window, attach a stream to it, and pass the stream as an
argument to READ.
Hopefully Lispworks provides some quick and dirty alternative for gathering
user input, but I have not been able to find it so far.
> (b) not be involving functions that are allowed to but not required
> to intervene between the point of your knowledge and the point
> of the call.
I have no idea what this means.
Roy
> Perhaps, in order to get user input into a program in Lispworks I need to
> create an input window, attach a stream to it, and pass the stream as an
> argument to READ.
> Hopefully Lispworks provides some quick and dirty alternative for gathering
> user input, but I have not been able to find it so far.
If you simply want to get a form from the user, then
capi:prompt-for-form may be suitable. (see online documentation).
Clive Tong <··········@scientia.com> writes:
> > Perhaps, in order to get user input into a program in Lispworks I need to
> > create an input window, attach a stream to it, and pass the stream as an
> > argument to READ.
> > Hopefully Lispworks provides some quick and dirty alternative for gathering
> > user input, but I have not been able to find it so far.
>
> If you simply want to get a form from the user, then
> capi:prompt-for-form may be suitable. (see online documentation).
Also, *query-io* is always supposed to be available for user I/O, if
that's what's wanted.
I even think LW does something clever with watching output to *query-io*
and buffering it up as a prompt to the next call to various operations
like read and read-line, which I think it turns into calls to functions
portable wouldn't know about like capi:prompt-for-form or the like. I
had this happen the other day to me and was a little surprised, but it
seemed to do the right thing.
Clive,
> > If you simply want to get a form from the user, then
> > capi:prompt-for-form may be suitable. (see online documentation).
It woiks! --Both from the Listener Window and the Editor Window. Thanks.
I had searched the dozen pdf manuals that came with LW for references to
READ,
but had missed the CAPI section on user prompts.
Kent,
> Also, *query-io* is always supposed to be available for user I/O, if
> that's what's wanted.
I tried
(read *query-io* nil 'eof)
but this resulted in no pause for user input, and evaluated as EOF.
Doubtless I'm unclear on the concept.
Roy
"Roy Mash" <········@ci.sf.ca.us> writes:
> I tried
> (read *query-io* nil 'eof)
> but this resulted in no pause for user input, and evaluated as EOF.
> Doubtless I'm unclear on the concept.
Not necessarily. If you have a supported version, I'd report this as a
bug. If you have LWW Personal Edition, you now have at least some
possible motivation for paying for a real copy--to get ongoing bugfixes.
I know of no obvious reason that *query-io* should ever be at eof
under normal circumstances.
In LWW 4.1.20 Enterprise, when I do
(progn (format *query-io* "~&Foo: ") (read-line *query-io*))
or
(progn (format *query-io* "~&Foo: ") (read *query-io*))
or
(progn (format *query-io* "~&Foo: ") (read *query-io* nil 'eof))
I get pop-up input boxes with a "Foo:" prompt.
"Kent M Pitman" <······@world.std.com> wrote in message
····················@world.std.com...
> In LWW 4.1.20 Enterprise, when I do
> (progn (format *query-io* "~&Foo: ") (read-line *query-io*))
> ...
> I get pop-up input boxes with a "Foo:" prompt.
Cool -- I do too!! But I still get EOF if I omit the (format ...)
and just give these forms by themselves:
(read *query-io*)
or
(read-line *query-io*)
Why would a preceding FORMAT be necessary for READ?
thanks,
roy
"Roy Mash" <········@ci.sf.ca.us> writes:
> "Kent M Pitman" <······@world.std.com> wrote in message
> ····················@world.std.com...
>
> > In LWW 4.1.20 Enterprise, when I do
> > (progn (format *query-io* "~&Foo: ") (read-line *query-io*))
> > ...
> > I get pop-up input boxes with a "Foo:" prompt.
>
> Cool -- I do too!! But I still get EOF if I omit the (format ...)
> and just give these forms by themselves:
> (read *query-io*)
> or
> (read-line *query-io*)
>
> Why would a preceding FORMAT be necessary for READ?
Sounds like just a bug to me.
Kent M Pitman <······@world.std.com> writes:
> In LWW 4.1.20 Enterprise, when I do
>
> (progn (format *query-io* "~&Foo: ") (read-line *query-io*))
>
> or
>
> (progn (format *query-io* "~&Foo: ") (read *query-io*))
>
> or
>
> (progn (format *query-io* "~&Foo: ") (read *query-io* nil 'eof))
>
> I get pop-up input boxes with a "Foo:" prompt.
As do I in LW/Linux 4.1.20 Professional. But if you do a simple (read
*query-io* nil 'eof) or (progn (format *query-io* "") (read *query-io*
nil 'eof)) it immediately returns 'eof.
--
Lieven Marchand <···@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words