Re: single SchemeUnit code base

I wrote:
> One of the things I'm looking into is whether it would be possible to
> have a single code base for SchemeUnit for MzScheme and SISC.

MJ Ray wrote:
> It's definitely possible. There are various mechanisms for doing it,
> including have different top-level files and then common included
> files, or using a system like Dorai Sitram's scmxlate or Hans
> Oesterholt-Dijkema's staste.
>
> http://www.ccs.neu.edu/home/dorai/scmxlate/scmxlate.html
> http://www.elemental-programming.org/epwiki/EP%20Scheme%20-%20Staste

Thank you for these links to prior art!  I hadn't known about them
before.

Now, I should explain, when I said "is it possible" what I actually
was thinking was "can I find a solution that meets all of my various
competing desires that I haven't articulated yet" :-)

So!  I will attempt to actually articulate my desires...

Noel Welsh wrote:
> My current thinking is [having common included files].  I don't
> believe the other frameworks are really necessary nor would provide
> the degree of integration with the host language that I want.

Right, I don't want to have to run a preprocessor every time I make a
change to my program, or lose the integration with the host language.

Let's take a look at the common include file option.

Suppose we had assert-util.inc with just the definitions:

  ;; syntax->location-values : syntax -> list
  (define (syntax->location-values stx)
    (list (syntax-source stx)
          (syntax-line stx)
          (syntax-column stx)
          (syntax-position stx)
          (syntax-span stx)
          (syntax-source-module stx)))

  etc...


And an assert-util.ss wrapper for PLT:

  (module assert-util mzscheme

    (require (lib "plt-match.ss")
             "assert-base.ss")

    (provide syntax->location-values
             location->string
             get-assertion-info
             get-assertion-name
             get-assertion-params
             get-assertion-location
             get-assertion-expression
             get-assertion-message)

    (include "assert-util.inc"))


And an assert-util.scm wrapper for SISC:

  (require-library 'schemeunit/mzcompatibility)
  (require-library 'schemeunit/assert-base)

  (module schemeunit/assert-util

    (syntax->location-values
     location->string
     get-assertion-info
     get-assertion-name
     get-assertion-params
     get-assertion-location
     get-assertion-expression
     get-assertion-message)
  
    (import string-io)
    (import schemeunit/assert-base)
    (import schemeunit/mzcompatibility)

    (include "assert-util.inc"))


Now, this is pretty good.  There's no code duplication in the
implementation, and the code can be directly loaded and compiled by
both PLT and SISC.

Which doesn't mean I'm actually *satisfied*.  I'm greedy enough to
want something even better.  As a programmer, I'm quite lazy, and when
I write code, I don't want to have to define a procedure in one place,
and then add it to a wrapper for PLT, and then add it again to a
wrapper for SISC.  That's the kind of tedious activity that I'd much
prefer to have my computer do for me!

My first preference is to have some macros which expand my code into
either a PLT module or an SISC module as required.  That seems like
just the kind of transformation that a macro should be good at, and
with source location tracking, I don't lose any integration with the
host language.

SISC is quite flexible about modules and macros.  Want to have a macro
that expands into a module?  Sure, no problem!  I don't know enough
about PLT yet to know what can be done in PLT.

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