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 [email protected] 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 [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
