[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Scheme-reports] Opinion about R7RS
- To: scheme-reports@x
- Subject: [Scheme-reports] Opinion about R7RS
- From: Jean-Michel HUFFLEN <jmhuffle@x>
- Date: Fri, 29 Jun 2012 18:57:30 +0200
Please find hereafter my comments about the draft for R7RS.
My main comments are about characters and encodings.
The description of the "read-char" function does not mention any
Is there a default encoding? ASCII since implementations of Scheme are
required to deal with the full range of Unicode, but only with the part
U+0000..U+007F? Of course, the same question holds for the "write-char"
I think that Scheme should provide input procedures that deal with
encodings such that Latin-1, UTF-8, UTF-16, and others. Maybe some
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. So users can implement themselves
encodings---if need be---by using bytes or bytevectors.
By the way, an useful function about text files would return the
used. On Unix and Mac OS X, this function could be implemented by
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
On another point, there is some ambiguity about functions like
Let us consider the "char-alphabetic?" function implemented by a
interpreter that only implements the Latin 1 encoding. In particular,
implements ASCII, so that is permitted, but it does not implement the
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
#f since it not Unicode-compliant. But the second choice would mean
answer may be implementation-dependent.
A second problem: let us assume that we are implementing a small
interpreter for a classical programming language, "classical" in the
that only letters belonging to the ASCII encoding can be used to build
identifiers. So this "char-alphabetic?" function will be unusable when
write the lexical analyzer of this language in Scheme. From my point of
a better choice would be:
- a "char-alphabetic?" function retaining only the ASCII letters,
compatibly with the namesake function of previous standards;
- a new "u-char-alphabetic?" function retaining letters, as far as
possible, depending on the range of characters provided; in other words,
will retain the letters of Latin-1 (resp. Latin-2) if it implements the
Latin-1 (resp. Latin-2) encoding; in particular, if the full range of
is implemented, all the letters of Unicode will be retained.
Of course, the same remarks hold about the functions "char-numeric?",
"char-whitespace?", "char-upper-case?", "char-lower-case?".
The last two points already existed in previous standards, but I
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.
I think that the first sentence should be reformulated.
The "values" function should be defined better about the equivalence:
(values X) == X
The report reads:
The "values" procedure might be defined as follows:
(define (values . things)
(call/cc (lambda (cont) (apply cont things))))
In such a case, we can easily prove that (values X) ==> X. But "might
defined" can be interpreted "might be defined or might not be defined".
rough implementation of this function is:
(define (values . things)
(lambda (f) (apply f things)))
However, this implementation seems to me to be correct w.r.t. the
of the "values" function, but obviously the equivalence is not true.
If the equivalence is true, that means that we can use the "values"
function as the identity function when it is applied to one argument.
Besides, this feature is used within the proposed implementation of some
SRFIs. If this equivalence is false, we cannot. So, I think that the
description of "values" should be more precise: mention that the
is true or implementation-dependent.
This message was sent using IMP, the Internet Messaging Program.
Scheme-reports mailing list