[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Portability (long)
I have no objection to attempting to gain concensus on language and library
issues that we believe are well understood. I believe, however, that many
of the issues you describe are not well understood or are not concerned
with the language or its libraries. In particular, many of your issues
concern facilities intended for use by a human programmer and not by
An example of an issue that clearly falls within the language or its
libraries is random access operations on ports for which they make sense,
such as a file input port.
An example of an issue outside of that domain is the notion of a
real-eval-print loop or a ``host system''. I strongly oppose
standardization of such notions because they are not universal in any
sense. You claim that you have ``not seen too many Lisps without a Read
Eval Print Loop which has a way of RESETing to the top level and EXITing to
the host system''. I have seen several, including Xerox Lisp and Symbolics
Genera; in these systems, there is no such thing as a ``host system'' and,
in Xerox Lisp at least, no institutionalized notion of a ``top level'' to
which one might return.
The Scheme language committees should not be concerned with a programmer's
ability maneuver in the user interface of an implementation. If, in a
particular implementation, the programmer cannot figure out, without
reading the documentation, how to manipulate a read-eval-print loop, it is
not an issue for the committees designing a language. We are not
attempting to design or standardize upon a user interface.
I have also not seen any response to, I think, Jinx's point about
extra ``compile'' and ``load'' files that test which implementation
use and coordinate things appropriately.
There is *no* standard way of finding out what implementation is
Of course there is: the human setting up the system can simply read the
name on the box containing the software. Come on, now; how hard can it be
for the human programmer to choose the appropriate system-dependent
I usually find some system code I can't recompile
with (e.g.) VECTOR? integrated
Why is this an issue for standardization? If you're making changes to
``system code'', by which I assume you mean parts of some particular
implementation, then you're already completely non-portable. If that
implementation doesn't tell you all of the fancy hacks that they use in
preparing their system code, complain to them, not to the standardization
Assuming a syntax system and a yellow pages (Real Soon Now...), the
minimum I see is the ability to query an implementation to find out its
name and version (Nice to get Operating and Filesystem likewise and what
numerics, etc. are supported).
You don't need this in your program. Let the human do it.
Among your lists of desired interfaces, you include:
Basic error handling, tracing
Compiler and Inspector invocation
Error handling is a deep area in which I would be glad to see some
significant work done. I'm more than willing to consider seriously any
proposal that deals with the issues well. For example, I would love to see
someone work on discovering the clean kernel of ideas in the
useful-but-baroque Common Lisp condition system (sorry, Kent). I would, on
the other hand, object strongly to any patchwork solution unless we can get
concensus that it is a part of any ``real'' solution we might later adopt.
I don't want to standardize on short-term hacks.
Tracing and invocation of other implementation-dependent programming
environment facilities is not an appropriate area for standardization.
Programs don't type these commands, humans do; let those humans read that
particular system's documentation, if any.
In conclusion, I am not against the Scheme specification including the
interfaces to certain essentially universal libraries. I am, however,
opposed to any standardization of the user interface. In those cases where
standardization is appropriate, I would like to see very precise proposals
that clearly address the complete issue, rather than short-term patches.