[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
back messages
Wed 19 Feb 86 11:10:35-MST SANDRA <LOOSEMORE@UTAH-20.ARPA>
buffered output and prompting
I'm having trouble coming up with a portable way for a CL application
program to read with a prompt string. What I would like to do is something
like, but more general than, the y-or-n-p and yes-or-no-p functions:
specify a prompt string and then call read, read-line, or read-char. For a
usual terminal-style interaction, I'd like to have the prompt message
printed out without a newline so the cursor is left at the end of the same
line, and then read. Aside from the fact that writing out the prompt string
directly prevents you from using alternative interaction styles (like a
pop-up dialog box or whatever), it's unclear that you could guarantee
the same behavior, or even reasonable behavior, in all CL implementations.
CLtL implies that buffered i/o is perfectly acceptable, so I assume one would
have to do a (finish-output) after printing the prompt message to ensure that
it really does get printed. However, emptying the internal buffer may mean
that the prompt message shows up with a newline on the end, particularly if
the output stream is organized into records with an implicit newline at
the end of each record. (This is also acceptable, according to page 22.)
Furthermore, the terminal driver provided by the operating system may
include some fancy input editing capabilities that are confused by printing
out random prompt strings; to get the prompt to interact properly with the
editor, you have to pass it to the read function provided by the operating
system. (In fact, all three of these conditions are true under VMS.)
PSL has a variable that holds the current prompt string, and it's used
whenever you read from the terminal. Different PSL implementations use
whatever hooks the OS provides to get the right effect. I also seem to
remember that the NMODE editor does special things with the prompt string
that are more appropriate for its style of interaction. The point is, the
same code will produce reasonable behavior in all situations. How can I
get similar portability in CL code? Do we need to define additional
functions (or additional arguments to existing functions) to support user
interaction?
-Sandra
-------
Wed, 19 Feb 86 14:10 EST <MOON@SCRC-QUABBIN.ARPA>
Re: Basic Design Questions: function cells
Date: Wed, 19 Feb 86 11:24 EST
From: "Eric J. Swenson" <Swenson@CISL-SERVICE-MULTICS.ARPA>
I too don't understand the arguments of the efficiency of the function
cell concept,
I believe these arguments were comparing storing function definitions in
dedicated cells to storing them in property lists. As far as I know no
one has argued that having functions and variables in separate name spaces
leads to a more or less efficient implementation than having them in the
same name space. I could be wrong; people will argue for almost anything.
however, from the standpoint of looking at CL as a NEW
language (as opposed to a pot-pouri of all the existing Lisp dialects)
it certainly seems that CL is clutterred with pairs of functions/macros
to deal with functional and non-functional objects and that elegance has
been sacrificed in order to maintain compatibility with the various
older Lisp dialects. I take it that the overriding factor in CL
development has been compatilibity with the major Lisp dialects as
opposed to designing a new language which was more internally consistent
and conceptually elegant?
That's certainly true. At the same time, it is a matter of opinion
whether having all of the dozens of possible classes of named objects in
the same space, or each in a separate space, is more elegant. The issue
is not only variables and functions. Without going into extensions to
Common Lisp, you can also think about package names, type names, and module
names. There are powerful arguments on both sides of this issue. All
a language designer can do is pick one philosophy and then be consistent
about it.
----
Wednesday, February 19, 1986 12:02:30 Alan Snyder <snyder@hplsny>
Re: Basic Design Questions: function cells
I believe these arguments were comparing storing function definitions in
dedicated cells to storing them in property lists. As far as I know no
one has argued that having functions and variables in separate name spaces
leads to a more or less efficient implementation than having them in the
same name space.
My impression was that having a separate function cell can be more efficient
because it allows function invocation to be compiled into a direct jsr (or
jump) through the function cell, with no explicit check that the function is
defined (undefined functions are represented by a special undefined-function
function). Using the same cell for functions and other variables would
require checking that the cell contains a function before calling it
(otherwise you might transfer control to a random location).
-------
19 Feb 1986 1243-PST (Wednesday) berman@isi-vaxa.ARPA (Richard Berman)
Re: Basic Design Questions: function cells
I believe these arguments were comparing storing function definitions in
dedicated cells to storing them in property lists. As far as I know no
one has argued that having functions and variables in separate name spaces
leads to a more or less efficient implementation than having them in the
same name space.
My impression was that having a separate function cell can be more efficient
because it allows function invocation to be compiled into a direct jsr (or
jump) through the function cell, with no explicit check that the function is
defined (undefined functions are represented by a special undefined-function
function). Using the same cell for functions and other variables would
require checking that the cell contains a function before calling it
(otherwise you might transfer control to a random location).
-------
The function cell can also hold the lambda expression for an interpreted
function, so you can't do a blind JSR anyway.
RB
------
19 Feb 1986 12:39-PST MATHIS@USC-ISIF.ARPA Standardization proposal
Today I sent a proposal to X3 for the establishment of a
technical committee for the development of an American National
Standard for Common Lisp. This committee will probably have the
designation X3J13.
Following their normal time-table, the committee will probably be
approved in early summer and the first official meeting will be
in Washington, DC in September 1986. Membership will be open
according to X3 rules (basically attendance, participation, and
payment of fees).
The proposals are available as net mail, but I would rather only
send them to interested people. If you are interested in seeing
the proposals or participating on the X3J13 committee, please
respond and give me your non-arpa-net addresses as well.
Bob Mathis 9712 Ceralene Dr Fairfax, VA 22032-1704 (703)425-5923
------
Wed, 19 Feb 86 15:40 EST Guy Steele <gls@THINK-AQUINAS.ARPA>
Function cells
My memory is that a question arose as to whether, given that function
cells and value cells were to be distinct, they should have identical
binding mechanisms or not. There was no compelling reason to allow
special binding of function names, and the following argument was
advanced against such special bindings: multiprocessing implementations
of Lisp might well prefer to use deep special binding, and it was
undesirable to have to deal with the deep binding mechanism for function
lookups, given that most function-name references, unlike most
variable-name references, occur free. I recall that this was the
deciding argument that eliminated special binding of function names from
Common Lisp, thereby making function names and variable names dissimilar
in their semantics and further discouraging their merging.
I can report that much of the time I am very happy to have the two names
spaces be distinct. I get very unhappy whenever I find myself inventing
functionals (functions that take other functions as arguments or return
other functions as values) for various purposes. For example, I have
found it semantically convenient to do so in Connection Machine Lisp.
In these situations I find the need for interpolated occurrences of
"funcall" and "#'" extremely annoying.
--Guy
------
Wed, 19 Feb 86 14:29:56 MST kessler%utah-orion@utah-cs.arpa (Robert Kessler)
re: Function Cells
> The function cell can also hold the lambda expression for an interpreted
> function, so you can't do a blind JSR anyway.
That is not true. One simply stores the lambda expression on the property
list and stores a call to "CompiledCallingInterpreted" compiled function
in the function cell. "CompiledCallingInterpreted" picks up the lambda
expression from the property list and performs normal interpreted evaluation.
PSL also stores a reference to "UndefinedFunction" in newly made symbols
which causes the undefined function processing to be handled. Thus you can
guarentee that the function cell always contains an executable function
address and never need to check.
Bob.
------
Wednesday, February 19, 1986 14:21:00 Alan Snyder <snyder@hplsny>
Re: Basic Design Questions: function cells
The function cell can also hold the lambda expression for an interpreted
function, so you can't do a blind JSR anyway.
Your assumption that the lambda expression for an interpreted function must be
stored in the function cell is incorrect. PSL used the implementation
technique that I described, with good results.
-------
19 Feb 86 15:42 PST Fischer.pa@Xerox.COM
Re: transfer control to a random location
Why should Common Lisp worry about this efficiency? It "would be an
error" just like so many other things that can destroy a "fast" Common
Lisp.
Now if you mean this is one small case where the language favors a
conventional machine...
(ron)
------
Wed 19 Feb 86 18:00:48-PST Martin <GRISS%HP-HULK@HPLABS>
Re: Basic Design Questions: function cells
Return-Path: <@SU-AI.ARPA:berman@isi-vaxa.ARPA>
Received: from hplabs.ARPA by HP-HULK with TCP; Wed 19 Feb 86 13:15:15-PST
Received: from SU-AI.ARPA by hplabs.ARPA ; Wed, 19 Feb 86 13:16:12 pst
Received: from ISI-VAXA.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 12:41:30 PST
Received: by isi-vaxa.ARPA (4.12/4.7)
id AA04673; Wed, 19 Feb 86 12:43:16 pst
From: berman@isi-vaxa.ARPA (Richard Berman)
Message-Id: <8602192043.AA04673@isi-vaxa.ARPA>
Date: Wed, 19 Feb 1986 16:43:00 -0000
Cc: Alan Snyder <snyder@hplsny.ARPA>
Subject: Re: Basic Design Questions: function cells
To: common-lisp@su-ai.ARPA
I believe these arguments were comparing storing function definitions in
dedicated cells to storing them in property lists. As far as I know no
one has argued that having functions and variables in separate name spaces
leads to a more or less efficient implementation than having them in the
same name space.
My impression was that having a separate function cell can be more efficient
because it allows function invocation to be compiled into a direct jsr (or
jump) through the function cell, with no explicit check that the function is
defined (undefined functions are represented by a special undefined-function
function). Using the same cell for functions and other variables would
require checking that the cell contains a function before calling it
(otherwise you might transfer control to a random location).
-------
The function cell can also hold the lambda expression for an interpreted
function, so you can't do a blind JSR anyway.
RB
Actually, in our CL implementation, and in PSL before it, there is a
compiled LAMBDA handler function (or "thunk") to which you JSR; it
finds the associated S-expression wherever it is (or reconstructs, or
whatever).
Martin Griss
-------
19 Feb 1986 21:36-PST David Bein <pyramid!bein@sri-unix> reading floats..
What do others think the reader for floating point numbers
should do when it calculates a 0 mantissa (for float-digits
equal to 53 this would be 4503599627370496 in terms of
a 53 bit 1.F value) and the smallest exponent which would be 0.0
if given to scale-float? (Assume the digits are non-zero)..
I can see one of the following possibilities:
(1) Could be quiet and produce the smallest possible non-zero
float of the desired type.
(2) Could be quiet and return 0.0.
(3) Could complain about non-zero digits turning into 0.0.
(4) Compute it in a higher format if possible and let it die
when converting that to the desired format.
Note that this question also covers what would be described
as exponent underflow since the mantissa for that would be
too small if we shift the exponent to be in range.
I vote for #3. Note that a proper printer based upon Guy
Steele's "How To Print Floating Point Numbers.." will not
produce digits which fall into this class, so this is only
a question for "virgin" input.
--David