larcenists / larceny

Larceny Scheme implementation
Other
202 stars 32 forks source link

Issues with SRFI 64 implementation #763

Closed mnieper closed 8 years ago

mnieper commented 8 years ago

I have noticed the following two issues of the SRFI 64 implementation provided by Larceny:

1) Larceny's simple test runner writes a log file that is being opened in the lines following https://github.com/larcenists/larceny/blob/master/lib/SRFI/srfi-64.sch#L309 when the current group stack is being empty. However, it is being closed by https://github.com/larcenists/larceny/blob/master/lib/SRFI/srfi-64.sch#L339 at the end of every group (not only the primordial one). This results in Larceny only logging the results of the test group that ends first.

2) Larceny's implementation fails the test 2.1.2 of SRFI 64's testing suite http://srfi.schemers.org/srfi-64/srfi-64-test.scm, that tests test-error in the absence of any error. As far as I see it, the problem is due to the following: In https://github.com/larcenists/larceny/blob/master/lib/SRFI/srfi-64.sch#L858, test-error is expanded into an invocation of test-assert, which invokes %test-error. Both in turn invoke %test-comp1body, which reports the test result in https://github.com/larcenists/larceny/blob/master/lib/SRFI/srfi-64.sch#L660. Thus by one call of test-error, two test results are generated. (In case of test 2.1.2 a pass and a failure is generated, while the SRFI 64 self test only expects a failure.)

Speaking of test-error there seems to be another problem in line https://github.com/larcenists/larceny/blob/master/lib/SRFI/srfi-64.sch#L825: In case no error is caught, the result of evaluating expression is returned. If this expression does not evaluate to #f, it may not be distinguishable to the value #t, which would be returned by guard in case of an error. In the current version of the reference implementation, this problem is solved by always returning #f in case no error is caught: https://github.com/scheme-requests-for-implementation/srfi-64/blob/master/testing.scm#L879.

WillClinger commented 8 years ago

All of those issues should be fixed by changeset eef999701f186b216cd3ef65bc2b34c0edbd7a02