[Bug-openmcl] open :element-type

[Gary Byers]

On Thu, 22 Jan 2004, bryan o'connor wrote:

> :element-type is unfairly restricted to ([un]signed-byte 32).

Who says it's unfair ?

>
> the standard says, "a type specifier for recognizable subtype of
> character; or a type specifier for a finite recognizable subtype
> of integer; or one of the symbols signed-byte, unsigned-byte, or
> :default. The default is character."

Oh, right.  -That's- who says it's unfair.

>
> (open "tmp.dat" :direction :output
> 		       :if-exists :supersede
> 		       :element-type '(unsigned-byte 33))
>
> the restriction seems to be in make-heap-buffer.  removing it
> does fix the problem.. but i imagine it's also creating some.
>

The dictionary entry for OPEN uses the term "reasonable" a couple
of times, noting that it's impossible for OPEN's behavior to be
fully specified in light of file-system differences.

It would probably be reasonable for a 32-bit implementation to error
on an element-type of (UNSIGNED-BYTE 1000000000000000) even though
that's a finite recognizable subtype of INTEGER.

Filesystems that this implementation runs on express position and
length in terms of 8-bit octets, so unless an integer element type is
upgraded to a multiple of 8 bits it's not always possible to reliably
append to a file, or to report or seek to a specified position, so
that kind of element-type upgrading seems reasonable.  (Letting
these operations fail or return NIL might also be reasonable.)

It's probably not too hard to support element types that are multiples
of 8 bits up to some threshold.  Currently, that threshold's 32.  A
larger threshold might be nice (especially if anything but the test
suite had a need to deal in larger elements), but it's not clear to me
that the implementation -has- to support arbitrararily wide element
types or that a portable program can make too many assumptions about
what will be accepted without error.


> 						...bryan
>
> _______________________________________________
> Bug-openmcl mailing list
> Bug-openmcl at clozure.com
> http://clozure.com/mailman/listinfo/bug-openmcl
>
>