Decide distinction string vs. bytevector is a hard-requirement

[okuoku]

Unfortunately, Bigloo lacks string vs. bytevector distinction. Previously, MIT/GNU Scheme also fallen into this area but recent MIT/GNU Scheme 10 gained this.

So far, Bigloo is only (actively-developed) Scheme that lacks this.

Bigloo lacks:

• Generic binary port: In Bigloo, it is for object serialization thus SRFI-6 styled buffered port is not available
• Generic utf8 string: Bigloo has special UCS2 string type

[lassik]

By way of a quick test, Bigloo 4.3h differentiates between strings and bytevectors, but it uses the name "u8vector" (SRFI 4) instead of "bytevector" (RnRS):

1:=> (string? "foo")
#t
1:=> (u8vector? "foo")
#f
1:=> (string? (make-u8vector 10))
#f
1:=> (u8vector? (make-u8vector 10))
#t

Not sure whether this is the case using all compiler backends (if I understood correctly, it has at least C and JVM backends, plus an interpreter).

It currently seems to be missing specifically:

• The R7RS routines whose names start with bytevector
• utf8->string and string->utf8
• open-binary-input-file and open-binary-output-file
• open-input-bytevector and open-output-bytevector

The manual https://www-sop.inria.fr/indes/fp/Bigloo/manual.html says:

Unicode support: Bigloo supports UCS-2 Character encoding and also provides conversion functions between UTF-8 and UCS-2. It still maintains traditional ISO-LATIN1 characters and strings.

[lassik]

@manuel-serrano: Do you have plans to add bytevector procedures with standard (R6RS/R7RS) names in the future?

[okuoku]

Yup, Bigloo has U8VECTOR type

https://github.com/manuel-serrano/bigloo/blob/db18c77b244f95acbed6a4ea4f3c69ae21d29731/runtime/Include/bigloo.h#L388

and is exposed to the C backend. It is no matter which naming used (ie. SRFI-4 u8vector vs. RnRS bytevector) since Yuni can provide wrapper for it.

The whole point is SRFI-4 is not on the "supported SRFI" list of the manual. I guess it's because of Java backend but anyway it won't play well with existing Bigloo tooling; in Bigloo library, most binary related procedures take bstring type and not u8vector. So I think it'd be better to stick with string-everywhere on Bigloo so users can freely intermix Bigloo libraries and Yuni (w/ RnRS-styled bytevector APIs).