[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Kastrup
Subject: Re: Status of Guile 2.0 Support (Next Debian release won't ship guile-1.8)
Date: Sun, 21 Sep 2014 22:02:17 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

David Kastrup <address@hidden> writes:

> It's not clear how long I'll take to wear down the bugs.  Half of them
> are other things that go "ugh", like GUILE being of the opinion it knows
> how to deal with various character encodings, reinterpreting strings as
> byte streams and vice versa in situations where it does not make sense.

Here is an example:

;(setlocale LC_ALL "")
(define s (list->string (map integer->char '(20 200 2000))))
(with-input-from-string s
  (lambda ()
    (let loop ((ch (read-char (current-input-port))))
      (if (not (eof-object? ch))
            (format #t "~d\n" (char->integer ch))
            (loop (read-char (current-input-port))))))))

Without reactivating the outcommented setlocale line, this will crash.
And it will not crash when defining s: GUILE is fine with defining
strings with large characters.  Strings are character-set agnostic.

Instead it will crash on with-input-from-string:

In ice-9/boot-9.scm:
 157: 7 [catch #t #<catch-closure 9552370> ...]
In unknown file:
   ?: 6 [apply-smob/1 #<catch-closure 9552370>]
In ice-9/boot-9.scm:
  63: 5 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 4 [eval # #]
In ice-9/boot-9.scm:
2320: 3 [save-module-excursion #<procedure 956bea0 at ice-9/boot-9.scm:3961:3 
3968: 2 [#<procedure 956bea0 at ice-9/boot-9.scm:3961:3 ()>]
In unknown file:
   ?: 1 [load-compiled/vm 
   ?: 0 [call-with-input-string "\x14�\u07d0" ...]

ERROR: In procedure call-with-input-string:
ERROR: Throw to key `encoding-error' with args `("scm_to_stringn" "cannot 
convert wide string to output locale" 84 #f #f)'.

Why would GUILE convert the string to an _output_ locale, just to read
it in again and convert it back according to an input locale?

Since with-input-from-string and with-output-to-string are used
liberally for working with character streams, the gratuitous encoding
and decoding turns a well-defined operation into something totally
opaque and mysterious.  And it's not like the backtraces win a price for
obviousness, either.

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.

At least that's how it appears to me.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]