string element types should perhaps be smarter
20211024
Issue text
string element types should perhaps be smarter
This is closely related to #24 (closed), but unlike that issue my suggested solution is, potentially, not completely compatible although I rather doubt anything will care.
(1.) read-file-into-string
opens the file with an external format specified by an argument to the function, but doesn't specify the element type. That means that in conforming implementations you'll always get character
, and on implementations like LW which have a make-thinner-strings-by-default option you may get an error if you specify an external format which will produce character
s (this is a deficiency in LW I think although it's the documented behaviour: I've suggested that open
could 'fatten' the stream in the case where the external format clearly implies character types larger than the default one).
I think a solution to (1) is to specify the element type as :default
which will explicitly produce an element type big enough for the external format. this keeps LW happy but also will mean that other implementations which may be able to produce thinner strings may actually be able to do that. On the other hand the element types of those strings will now not be character
so this is potentially a slightly incompatible change.
(2) write-string-into-file
also does not specify the element type of the stream. This can, again, break on LW for the same reasons as (1). I think it safe to specify it as :default
which means it will always correspond to whatever the external format implies.
I believe that (2) is a fully compatible change.