Hello,
On Mon, Jan 09, 2006 at 04:01:08PM -0800, Kon Lovett wrote:
> Or is it arbitrary? Are the parallel special forms to be used
> directly? Like (test-let <expected> ([...] ...) ...), where each test
> version of an expression has extra test attributes?
Yup, each test version of the more complicated primitives would have
had extra test attributes you used to inspect the evaluation and they
were meant to be written in directly.
So, like:
(test-let MESSAGE (warn MESSAGE) EXPECTED
((expect-bind MESSAGE EXPECTED BIND-CLAUSE)
(expect-bind MESSAGE EXPECTED BIND-CLAUSE)
(expect-bind MESSAGE EXPECTED BIND-CLAUSE)
(expect-bind MESSAGE EXPECTED BIND-CLAUSE))
(todo "implement me"))
BIND-CLAUSE would be something like:
(x (+ 1 2))
which you would normally see there in the let form...
This way, you could test to see if your bindings were correct before you
used them in your tests.
Ultimately, this leads to a dialect of scheme where you have the
instrumentation and recording of the bindings/evaluations along
with expected results. The final resut can be visualized in any
particular fashion since the encapsulating data structure recording
the binding/evaluation _should be_ directly unalterable by the running
code. I think this is a nice thing, since you know DAMN well what it was
that happened and what was expected to happen at every (dare I say it)
continuation in the scheme code you are testing.
This method reminds me of a certain debugger where it instruments at
the continuation boundaries of the code. This isn't so much different,
except you assert what the values should be and actions to take if they
are wrong....
I suppose you could make a scheme -> test-infrastructure-dialect compiler
which would simply assign default values to everything and give you a
GUI to find and fill in certain expectations or place in functions (like
aspect programming) into continuations to see what the state of things
are. But, alas, I don't have time to implement that big old dream. :(
> I may chg the various tree-node representations into record-
> structures, for a slight speed-up. No visible API chg though. ("may
> chg" since they would need to be srfi-9 records as Chicken records
> are not common.)
One of my original design goal was to keep everything purely r5rs,
but that was around the time the SRFI process was really getting
accepted. So if you alter the internal structures to be SRFI-9 records,
I wouldn't mind.
> >Thank you for your contribution, I very much appreciate it.
>
> Your welcome. I committed a new release so it should be available
> soon. Has the TBD I mentioned earlier. I do plan to add Chicken
> compiler declarations to restrict the exported names, but this isn't
> a visible chg.
That'd be pretty cool too. Name pollution sucks.
-pete
_______________________________________________
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
