Why was ANSI Common Lisp designed with no simple means
(that I know of) of writing floating point values (arrays or
singletons) in binary format to files, and reading them back?
One might have thought that when READ/WRITE-SEQUENCE got introduced
a provision would have been made to do fast I/O for float vectors.
From: Barry Margolin
Subject: Re: ANSI Common Lisp design and floating point I/O
Date:
Message-ID: <dhSXa.32$Mg5.21@news.level3.com>
In article <··················@netnews.comcast.net>,
JP Massar <······@alum.mit.edu> wrote:
>Why was ANSI Common Lisp designed with no simple means
>(that I know of) of writing floating point values (arrays or
>singletons) in binary format to files, and reading them back?
Because the files produced this way won't be portable, since different Lisp
implementations have different floating point representations. If you're
going to write implementation-dependent files, you might as well use
implementation-dependent functions.
I realize this is not a great justification. Often the files will only be
used to pass data from one Lisp session to another within the same machine,
so data portability isn't a concern, but you'd like to be able to use the
same code on different systems. But it's the only rationalization I could
come up with.
In actuality, I guess it just wasn't considered a big issue. I don't
recall a mechanism for this in Maclisp or Zetalisp, which were the dialects
that contributed most to Common Lisp's design.
--
Barry Margolin, ··············@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Steven M. Haflich
Subject: Re: ANSI Common Lisp design and floating point I/O
Date:
Message-ID: <3F3132D1.1080608@alum.mit.edu>
Barry Margolin wrote:
>>Why was ANSI Common Lisp designed with no simple means
>>(that I know of) of writing floating point values (arrays or
>>singletons) in binary format to files, and reading them back?
>
> Because the files produced this way won't be portable, since different Lisp
> implementations have different floating point representations.
Actually, this is _also_ true for integer element-type files and read/write-byte.
There is no specification how the integers are represented on the external medium.
The programmer assumes that they will look something like the native data
representation of the data (perhaps modulo byte ordering) but the ANS would
permit, for example, printing in ascii decimal .
IMO this points to one of the areas where X3J13 messed up. CL I/O and characters
are and were always defined in terms of internal Lisp objects. Any specification
of the external representation was simply ignored, as if portability of programs
could be ensured simlpy by removing from consideration issues about portability
of external representation. That works, but only for programs that aren't much
concerned with interfacing with the external world. There may be some great AI
thesis implementations with that property, but how many current important Lisp
applications can live within that limitation? You can't even write a simple
web server without admitting that sockets exist and dealing with the byte-order
specifications.
At the time of X3J13 there were crucial political issues, such as the stock
hardware and lisp machine communities realizing that neither should or could
create any specifications that would be unnatural for the other. Perhaps that
was necessary, but it has ever since stood in the way of natural expression of
efficient, semi-portable external interface from CL programs.
Rememebr the mess in the late '70s when various groups tried to port C to the
PDP-10? C was seen to be a hot thing, but the poor PDP-10 had 36-bit words, and
36 is not evenly divisible by 8. Many C programs depended on the fact that
arbitrary swaths of memory could be moved or copied by copying contiguous bytes
(although the C language itself neither required nor supported this) but that
memory model wasn't easily portable to the PDP-10. If the CL community had been
defining C, we probably would have prevented this practice. But C became and
remains the de facto system implementation and glue language because it provides
so much obvious facility manupulating actual computer memory and bits and files.
From: Lars Brinkhoff
Subject: Re: ANSI Common Lisp design and floating point I/O
Date:
Message-ID: <85n0em79q7.fsf@junk.nocrew.org>
"Steven M. Haflich" <·················@alum.mit.edu> writes:
> Rememebr the mess in the late '70s when various groups tried to port
> C to the PDP-10? C was seen to be a hot thing, but the poor PDP-10
> had 36-bit words, and 36 is not evenly divisible by 8.
At least two C implementations for the PDP-10 use 9-bit chars by default.
--
Lars Brinkhoff, Services for Unix, Linux, GCC, PDP-10, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
"Steven M. Haflich" <·················@alum.mit.edu> writes:
> You can't even write a simple web server without admitting that sockets
> exist and dealing with the byte-order specifications.
Yes, but that's a byte issue. The 'shortcoming' of CL is not the
representation of characters as their own type, etc., nor the failure to
identify their internals, it's the paucity of functions for translating
bytes to characters and back. But, in fairness, the specs to/from which
we'd want to do that didn't exist back then. And implementations do
provide these functions.
> At the time of X3J13 there were crucial political issues, such as the stock
> hardware and lisp machine communities realizing that neither should or could
> create any specifications that would be unnatural for the other.
Which worked out well because we resisted the urge to put operations into
the language that would have been obsolete when the next character spec
came out from this or that ISO source. Instead, to progress, layered
character standards will be needed, which can be done without disturbing
the underlying design. This is as at least some of us intended--those of
us, at least, who knew the complexity and fragility of these specs.
It's why we eliminated int-char -- not to irritate users, and not to suggest
we thought there was no value in it, but to acknowledge that there was
insufficient world knowledge at the time of the standard to put together a
workable definition.
> Perhaps that was necessary, but it has ever since stood in the way
> of natural expression of efficient, semi-portable external interface
> from CL programs.
Yes, the goal of being both forward thinking in our design and anticipating
the actual individual details of all the things we were forward-thinking
about eluded us. I can't say as I'm ashamed.
> Rememebr the mess in the late '70s when various groups tried to port
> C to the PDP-10? C was seen to be a hot thing, but the poor PDP-10
> had 36-bit words, and 36 is not evenly divisible by 8. Many C
> programs depended on the fact that arbitrary swaths of memory could
> be moved or copied by copying contiguous bytes (although the C
> language itself neither required nor supported this) but that memory
> model wasn't easily portable to the PDP-10. If the CL community had
> been defining C, we probably would have prevented this practice.
> But C became and remains the de facto system implementation and glue
> language because it provides so much obvious facility manupulating
> actual computer memory and bits and files.
Yes, and CL does not as keenly address this market, at least in its
portable form. The nature of implementation details is that they
vary. The nature of CL is that it seeks to be like a 'good higlevel
manager' not a 'micromanager'. If we had glued ourselves to the base
layer of connectivity between us and the machine, there is no way we
would have had the power to escape the gravity of individual machines,
and we would be forever the low-level language that Lisp was. It's
only a tiny step from this kind of low-levelness to giving in on
automatic storage management and deciding to use malloc/free because,
again, some performance tricks require it to get that last cycle out
of the low-levels.
CL needs some bindings to ISO character specs. But it does not need
to acknowledge whether the bytes in those specs are machine bytes.
They might indeed be. But that's an implementation detail that if we
don't handwave away, we weigh down the language.