Let's start Scheme

2013-12-17

Edge case?

I've just found an interesting behaviour of R6RS implementation about bytevector output port. First of all, look at this piece of code;
(import (rnrs))

(let*-values (((port extract) (open-bytevector-output-port))
              ((out) (transcoded-port port (native-transcoder))))
  (put-string out "hello")
  (display (extract)))
What do you think the (extract) should do? According to the R6RS spec of transcoded-port the port must be closed by special way so that other string operations can be done.
As a side effect, however, transcoded-port closes binary-port in a special way that allows the new textual port to continue to use the byte source or sink represented by binary-port, even though binary-port itself is closed and cannot be used by the input and output operations described in this chapter.
-- R6RS Standard libraries 8.2.6 Input and output ports
I know open-bytevector-output-port can take a transcoder as its optional argument, however I think there is needs that the created bytevector output port needs to be converted later for some reason or user wants to store first pure binary data then some text data.

Now I've tried what the implementations would return, the result was rather interesting. Followings are the tested implementations and its result;

[Implementations that raised an error]
  • Larceny 0.97
  • Racket 5.2.1
  • Sagittarius 0.4.11
  • Ypsilon 0.9.6-update3
[Implementations that returned a bytevector]
  • Mosh 0.2.7
  • Petite Chez Scheme 8.4
The majority is raising an error, but interestingly Chez Scheme which I think the reference implementation of R6RS returned a value. For me, it is convenient the latter behaviour and the specification (as far as I searched) doesn't specify how it should be. The above quotation is only specifying the input/output operation not extracting.

Hmmmm, what should I do?

2 comments:

shiro said...

I think it's an oversight on a spec side. The intention of closing the binary port is just to avoid mixing binary and textual data. Extract operation won't affected by that issue, so it should be allowed. However some implementations just followed the spec literally.

kei said...

I was also thinking like that since the binary port will be useless after the conversion. And as long as the extraction returns a binary data so it doesn't have to care about weather or not it contains mixed data. (in a lot of cases I felt it was inconvenient that after the conversion the binary port was closed. well this is a different issue though.)

Post a Comment