Given the following example, using (rnrs unicode):
(string-foldcase "ΜΈΛΟΣ")
The expected result is "μέλοσ"; see R6RS libraries section 1.2. However
instead Guile's result is "μέλος". Note that although Σ usually
downcases to σ, at the end of a string it's ς. This test shows a
limitation of
R7RS defines a lexical feature called "datum labels"; see section 2.4 in
the report. An example would be:
#0=(a b c . #0#)
Guile's reader doesn't support this feature and it's not clear if we
should, in general. Note, datum literals appear to be incompatible with
array literals. But we coul
For R7RS, this should be true:
(file-error? (guard (exn (else exn)) (open-input-file " no such file ")))
However currently an error during Guile's open-input-file doesn't raise
a specific-enough exception for file-error? to be implementable.
Something to fix.
Guile has a strange syntax extension, as described in the bug title.
It's not explicitly documented AFAIU and it seems it may simply be a
mistake. We should consider making ( . 42) a lexical error.
Guile supports the R7RS idiom whereby this:
"foo\
bar"
reads as
"foobar"
In the R6RS, this syntax is specified as allowing intraline whitespace
(space, tab, and anything Unicode with category Zs) after the \ but
before the newline. However in Guile we don't support this and signal
an
I don't see where the incompatibility comes in, although more lookahead
would be required. Per the Guile documentation, neither #n# nor #n= (where
n is a sequence of digits) is a valid array tag.
On Sat, Nov 16, 2019 at 3:50 PM Andy Wingo wrote:
> R7RS defines a lexical feature called "datum la
