Re: Status of Guile 2.0 Support (Next Debian release won't ship guile-1.8)

[David Kastrup]

David Kastrup <address@hidden> writes:

> GUILE-1.8 already aborts at the attempt of converting 2000 to a
> character.  That's a clearcut limitation with understandable effects.
> But whatever you manage to turn into a character will then pass through
> strings or with-in/output-from/to-string or whatever else unmolested.
>
> GUILE-2.0, in contrast, accepts larger characters and then juggles
> around with them like hot potatoes.  It just has no clear concept, and
> then let's some external library (iconv or whatever it was) loose on it
> in the hope that running enough good external code in some manner will
> result in something everybody should like.

GUILE-2.2, by the way, _always_ encodes to UTF-8 upon encountering
with-input-from-string.  Why it would encode at all rather than just
taking the values from the string, I have no idea.  Now decoding input
in UTF-8 to a string and then reencoding the string to UTF-8 does not
necessarily lead to the same byte string, and LilyPond keeps the input
parsed by the LilyPond parser and the input parsed by Scheme in synch by
positioning at the respective offsets.  The LilyPond parser interprets
utf-8 itself (and gives out proper and detailed error diagnostics and
stuff for ill-formed utf-8) from the byte stream input, and the Scheme
parser works from an in-memory stream.

The result is that I can persuade GUILE-2.0 into synchronizing the byte
streams of LilyPond and Scheme parsing with some pain.  But come
GUILE-2.2, this road will be barred with the current approach, and file
reading and parsing will have to be completely rewritten.

-- 
David Kastrup