You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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):
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.
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).
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:
The text was updated successfully, but these errors were encountered: