From: Bruno Haible <bruno@cl...> - 2004-11-08 16:28:49
Sam Steingold wrote:
> De facto, I bet all CLs use the IEEE format in either the host byte
> order or some fixed byte order (either little-endian, like CLISP, or
> big-endian), so I see no harm in enabling CLISP to read all their files.
Which IEEE standard are you talking about? IEEE 754 is about floating-point
data, but Pascal wants to know about [UN]SIGNED-BYTE types.
If you know the format of a file another CL implementation has written,
you can read it in clisp: Use element type (UNSIGNED-BYTE 8) and put together
the integers using DPB. This code will be portable, since element type
(UNSIGNED-BYTE 8) seems to be handled the same way on all implementations.
Whereas I bet, the implementations differ significantly in their treatment
of element-types such as (UNSIGNED-BYTE 67) or (SIGNED-BYTE 3).
> > ANSI CL says that "The external-format is meaningful for any kind of
> > file stream whose element type is a subtype of character." You see,
> > it's not meant for binary I/O.
> So? We can do better, can't we?
There's no point in providing a clisp specific alternative for something
that you can already do in a portable way. Encourage portable programs,
not the converse!
Moreover, I disagree with any proposal that can handle only
([UN]SIGNED-BYTE n) where n is a multiple of 8, but fails to handle
(UNSIGNED-BYTE 67) and (SIGNED-BYTE 3).
Get latest updates about Open Source Projects, Conferences and News.