John Cowan wrote:
> Ben Goetter scripsit:
>
>> I would also add two new constructors that create a new textual input or
>> output port, given an existing binary port, a transcoder specification,
>>
> Per many previous postings, this is problematic unless (as in R6RS) the
> binary port is made unavailable for further use.
>
I could certainly live with that restriction in small-Scheme. However,
that's the intent of the octet count parameter, to wit:
>> and (optionally) the number of octets to {consume from, emit to}
>> that binary port.
>>
> What does that do?
>
Constrains the new "cooked" textual port to consume a particular number
of octets from the input source, or emit a particular number of octets
to the output sink. This allows the "raw" binary thing to remain
available for further use. It is not a panacea, but it does allow
buffering, as well as accessing fixed-width text fields in blobs.
>> Since I want binary and textual ports to be disjoint types, I would
>> also prefer to call binary ports something other than "binary port,"
>>
> Fine with me. Can list members offer any suggestions?
>
I like "raw-{input,output}" as an identifier, as a shorthand for "raw
input source" or "raw output sink." Because I think of this as raw vs
cooked, after the old 8-bit tty I/O usage.
Ben
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
