Jean-Michel HUFFLEN scripsit:

> The description of the "read-char" function does not mention any
> encoding.

That is correct: the WG postponed control of textual encoding to the
large language.

> Is there a default encoding?

The default encoding is implementation-dependent.

> Maybe some exotic encodings will not be provided by some Scheme
> interpeters, that is why a function should return a list of available
> encodings for an interpreter/compiler would be use ful.

The difficulty is that the implementation language being used may not
expose such a list (neither Java nor C# does so, for example).

> By the way, an useful function about text files would return the
> encoding used.  On Unix and Mac OS X, this function could be implemented
> by interfacing the "file" command. So, if we can known the encoding
> of a file and the encodings processed by a Scheme program, we will
> know if a text file will be directly processable.

At best, 'file' presents a guess.

> Let us consider the "char-alphabetic?" function implemented by
> a Scheme interpreter that only implements the Latin 1 encoding.
> In particular, it implements ASCII, so that is permitted, but it does
> not implement the full range of Unicode.  What would be the answer
> if this "char-alphabetic?"  function is applied to the letter "e with
> acute accent"?  Should this interpreter deal with Unicode properties
> as far as possible, or can it answer #f since it not Unicode-compliant.

It must return #t, because all the properties of whatever characters
the implementation provides must be correct according to Unicode.

> A second problem: let us assume that we are implementing a small
> interpreter for a classical programming language, "classical" in the
> sense that only letters belonging to the ASCII encoding can be used
> to build identifiers.  So this "char-alphabetic?" function will be
> unusable when we write the lexical analyzer of this language in Scheme.

Correct. In that case, you will have to write your own predicates.

> The description of the "call/cc" function begins with:
> It is an error if "proc" does not accept one argument.
> That is the standard case, but as it is recalled later in the text:
> Except for the continuations created by the "call-with-values" procedure
> [...], all continuations take exactly one value.

The escape procedures created by call/cc must not be confused with the
general notion of continuations.

--
John Cowan              cowan@ccil.org          http://www.ccil.org/~cowan
Most people are much more ignorant about language than they are about
[other subjects], but they reckon that because they can talk and read and
write, their opinions about talking and reading and writing are as well
informed as anybody's.  And since I have DNA, I'm entitled to carry on at
length about genetics without bothering to learn anything about it.  Not.
                        --Mark Liberman

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports