PLT-specific features

> I want to let you know I appreciate the work you are doing
> porting SchemeUnit to SISC.

You're welcome!

> Regarding the tension between portability and features ...
> I'd rather fork the code than lose a PLT-specific feature.

No no, I'd never suggest removing anything for PLT users!

If we can have have a single code base that runs under both PLT and
SISC, the behavior and public API of SchemeUnit under PLT should be
*identical* before and after.  No features lost.

Thus if I do propose making changes to the core SchemeUnit code, they
should be pure refactorings.  Any change in the behavior of SchemeUnit
under PLT would be a bug.

If this is achievable, there may be some loss of code clarity in the
guts of the SchemeUnit implementation.  For example, the definition of
FOLDTS currently reads:

  (define (foldts fdown fup fhere seed test)
    (match test
      ((struct test-case (name action setup teardown))
       (fhere name action setup teardown seed))
      
      ((struct test-suite (name tests setup teardown))
       (let loop ((kid-seed (fdown name setup teardown seed))
                  (kids tests))
         (if (null? kids)
             (fup name setup teardown seed kid-seed)
             (loop (foldts fdown fup fhere kid-seed (car kids))
                   (cdr kids)))))))

since MATCH hasn't been ported to SISC, I've rewritten this to:

  (define (foldts fdown fup fhere seed test)
    (cond
     ((test-case? test)
      (fhere (test-case-name test)
             (test-case-action test)
             (test-case-setup test)
             (test-case-teardown test)
             seed))
     ((test-suite? test)
      (let ((name     (test-suite-name     test))
            (tests    (test-suite-tests    test))
            (setup    (test-suite-setup    test))
            (teardown (test-suite-teardown test)))
        (let loop ((kid-seed (fdown name setup teardown seed))
                   (kids tests))
          (if (null? kids)
              (fup name setup teardown seed kid-seed)
              (loop (foldts fdown fup fhere kid-seed (car kids))
                    (cdr kids))))))
     (else
      (error "invalid type passed to foldts"))))

The two implementations of FOLDTS are supposed to have identical
behavior.  (Though I may have introduced some bugs at this point,
since I don't have the unit tests running yet!)

Now, from a code quality standpoint, the first version is better: it
is concise and clearly expresses the intention of the programmer.

If I myself were some day adding a feature to SchemeUnit or fixing a
bug, I'd prefer to work with code that looked like the first version.

However, the tradeoff between a single code base and forked versions
is that if I wanted to have my new feature or bug fix to work in both
PLT and SISC, with the forked versions I'd need to do my work twice.

Still it is not obvious to me a priori that a single code base is the
way to go.  It may not be possible, or it may reduce the code quality
of the PLT port to an extent that it outweighs the advantages of
having a single code base.

At this point I'm just keeping my eyes open and remaining alert for
opportunities to avoid making changes to the PLT version of the code.
Thus when I have an option between changing the PLT code and writing a
compatibility function or macro, I'll opt for writing the
compatibility layer.

Andrew Wilcox


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20