slib-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Slib-discuss] Three tests fail in formattst.scm


From: Kris De Volder
Subject: [Slib-discuss] Three tests fail in formattst.scm
Date: Sun, 14 Dec 2008 16:35:22 -0800

When I run the "formattst.scm" test under my implementation I get three
failed tests. I'm not sure what to put these failures down to:

  - bugs in my Scheme interpreter.
  - bugs in format.scm
  - incorrect tests in formattst.scm

So I was hoping to get some clarification from the people on this list
what the correct behavior for format would have to be on these tests.
I'll provide my interpretation and then hopefully people will be able to
clarify things, and correct my mistakes :-). I'll add to the end of this
message three detailed sections. One for each failed test.

But... here's the gist of it:

  - the implementation of format in format.scm seems to reset column
position to 0 at each call to format

  - the tests in formattst.scm seem to assume that column position
carries over from one call to the next.

This discrepancy appears to be the cause of the failed tests.

Question: which one is the true intent of format?

Thanks, 

Kris

--- First failed test -----------------------------------------------

*Failed* ("~&")
returns  ""
expected "
"

There's a few pieces of information I puzzled together:

a) I looked at the specification here (is this the right one?):
http://www.lispworks.com/documentation/HyperSpec/Body/22_cac.htm

        Unless it can be determined that the output stream is already at
        the beginning of a line, this outputs a newline. ~n& calls
        fresh-line and then outputs n-1 newlines. ~0& does nothing.
        
b) I looked at the implementation and it seems like the column position
is tracked with a variable local to the format function, which gets
initialized to 0 when format is called.

Thus, it seems that format assumes that the output is always at the
beginning of a line when it gets called. This explains why "" is
returned instead of a string containing a newline character.

c) I looked at the tests in formattst.scm. There are two tests with
"~&". I'm including the relevant test cases below:

        (test '("~3%") "
        
        
        ")
        (test '("~&") "")
        (test '("abc~&") "abc
        ")
        (test '("abc~&def") "abc
        def")
        (test '("~&") "
        ")

These tests seem to assume that the column position carries over between
successive calls to format (so the ~& behavior is different when the
previous call to format did/didn't end by moving the cursor to the
beginning of the line).

As far as I understand the code in "format.scm" (I admit I don't quite
understand it all), it keeps all mutable state local inside the format
definition, so its behavior can not possibly be altered by a previous
call to format.

I am not certain whether the "true intent" of format is as expressed by
the tests or as expressed by the implementation.

There is also a distinct possibility that my implementation is actually
to blame for making the format code misbehave. In any case, I need to
understand the "true intent" of format to get to the bottom of this.

---- Second failed test --------------------------------------------

*Failed* ("~10t")
returns  "          "
expected ""

Perhaps this is another example of the same discrepancy between the
implementation of format and the tests.

The test and the test preceding it:

        (test '("~0&~10t") "          ")
        (test '("~10t") "")

If we assume that the output is already at the start of the line for the
"~10t" then I believe it *would* be expected to return "          ". But
if we assume that the previous test already moved the output to column
10 it would just leave the cursor there.

---- Third failed test --------------------------------------------

*Failed* ("~,8t+++~,8t===")
returns  " +++     ==="
expected "     +++     ==="

Once again it seems to be a discrepancy between the tests assuming the
column position at the end of the previous test affects the next test.

        (test '("~0&12345~,8tABCDE~,8tXYZ") "12345    ABCDE   XYZ")
        (test '("~,8t+++~,8t===") "     +++     ===")

I think we would expect the test to return "     +++     ===" (5 leading
spaces) if we assume the column position after printing XYZ at the end
of the last test are 3 characters past the last ~,8t tab boundary.

However, if we assume that position is reset to 0, and that 
~,8t is really equivalent to ~1,8t (according to 
http://www.lispworks.com/documentation/HyperSpec/Body/22_cfa.htm
colnum and colinc default to 1). Then returning " +++     ===" would be
the expected behavior.

----

PS: I saw a comment in the slib docs 
http://people.csail.mit.edu/jaffer/slib_4.html#SEC57
that format is not "reentrant". It occurred to me that the code I looked
at does appear to be reentrant, since it has all mutable state neatly
tucked away inside of the format definition. Perhaps the "tucking away"
of the state has been done in order to make the code reentrant, but this
"broke" the tests that rely on column state being retained between
calls.

PS2: The email address@hidden listed in the format code doesn't
appear to work.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]