[Slib-discuss] Several (minor) glitches in testing format feature.

[Kris De Volder]

I'm currently trying to get formatst.scm to pass and ran into some
problems. 

I am posting them on the list because I think some of them may point to
possible problems in slib or at least an opportunity to improve
r4rsts.scm coverage. I also have some questions to help clarify some
details I'm not sure about.

1) mularg glitch with "/" for a fixnum only Scheme implementation

I propose to add a test to r4rstest to check whether (procedure? /) ->
#t to r4rstest.scm

Background info: From the way the r4rs itself reads, and the
r4rstest.scm file works, it seems to me that there is an intention to
allow implementations that only support exact fixnum arithmetic.

Currently my implementation is such an implementation and it passes the
r4rs test suite.

However, when I try to 

(require 'format)

> (require 'format)
slib:load "file:/home/kdvolder/workspaces/kscheme/ca.kscheme/bin/slib/format"
slib:load "file:/home/kdvolder/workspaces/kscheme/ca.kscheme/bin/slib/strcase"
slib:load "file:/home/kdvolder/workspaces/kscheme/ca.kscheme/bin/slib/sc4opt"
slib:load "file:/home/kdvolder/workspaces/kscheme/ca.kscheme/bin/slib/strport"
slib:load "file:/home/kdvolder/workspaces/kscheme/ca.kscheme/bin/slib/mularg"
ca.kscheme.interp.ErrorWithCont: Unbound identifier: / in
line: 9 col: 29 in 
file:/home/kdvolder/workspaces/kscheme/ca.kscheme/bin/slib/mularg.scm
 
I went and looked at the r4rs report and my interpretation w.r.t "/" is
that it is an "essential" procedure. Thus even a strictly fixnum
implementation should provide a definition, but the implementation may
report an error if it is called with arguments for which it cannot
accurately represent the outcome of the division.

Actually, the report only *recommends* that / when given exact arguments
should try to return exact results when possible. It does not actually
require it. Thus the report seems to demand that / be implemented but
would allow for a fixnum only implementation to simply signal an error
whenever it is called.

2) test in formattst.scm that test flonums without checking they are
supported by the implementation:

(load "formatst.scm")
...
error at line: 82 col: 1 in
file:/home/kdvolder/workspaces/kscheme/ca.kscheme/bin/slib/formatst.scm
    (test '("~a" -1.2) "-1.2")

I propose to change this line to:
    (if format:floats (test '("~a" -1.2) "-1.2"))

3) version discrepancy with sc4opt.scm?

Unbound identifier: list->string
line: 268 col: 4 in
file:/home/kdvolder/workspaces/kscheme/ca.kscheme/bin/slib/format.scm

First I thought that it was a missing (require
'rev4-optional-procedures)
but the require is actually there.

Looking into "sc4opt.scm" I see no definition of list->string however. 

I did find that this page:
http://www.cs.indiana.edu/scheme-repository/SCM/slib_5.html

tells there ought to be one.

But the more recent page at
http://people.csail.mit.edu/jaffer/slib_7.html

doesn't mention list->string

Looking in the r4rs report, it seems that it is an essential procedure,
which is probably why it was removed from sc4opt.scm.

Nevertheless in the r4rs test suite it is only tested for in the
"optional" test-sc4 procedure.

I resolved the issue for me by providing my own list->string
implementation and be more compliant with r4rs by making sure I pass the
sc4 tests.

I've got two specific questions about something that's not quite clear
to me here: 
  1) is there still an implementation of list->string provided in slib
somewhere? 

  2) is slib supposed to work with an implementation that doesn't pass
the sc4 tests?

I gather that *if* the answer to 1 = NO and 2 = YES this points to an
inconsistency where code making use of list->string is falling through
the cracks (in the sense that it depends on a procedure for which there
is no formal guarantee that it is provided either by the implementation
or another slib module).

Kris