RE: [stack] JoyUnit
Billy Tanksley — 2001-12-04 21:11:38
From: Brian C. Robinson [mailto:
brian.c.robinson@...]
>I just found Joy today as a result of a discussion on the
>extremeprogramming yahoogroup. I was wondering if there is
>any testing
>framework for Joy similat to jUnit for Java? I find it hard
>to develop without test these days...
No, but Joy isn't yet a language for serious "development". We hope it will
be, and no doubt a testing framework is a major part of that.
The best testing framework I've seen was for Forth, a language which shares
many characteristics with Joy; it was simply four words: "testing", "{",
"}", and "--". It was used like this:
...the definition of "+" deleted...
testing Commutative properties of addition
{ 3 4 + 5 + -- 3 4 5 + + }
Vary handy, very natural, and it ran at the same time as compilation -- the
tests usually directly followed the word's definition.
-Billy
Ocie Mitchell — 2001-12-04 23:44:45
--- Billy Tanksley <
wtanksley@...> wrote:
> From: Brian C. Robinson
> [mailto:brian.c.robinson@...]
>
> >I just found Joy today as a result of a discussion
> on the
> >extremeprogramming yahoogroup. I was wondering if
> there is
> >any testing
> >framework for Joy similat to jUnit for Java? I
> find it hard
> >to develop without test these days...
>
> No, but Joy isn't yet a language for serious
> "development". We hope it will
> be, and no doubt a testing framework is a major part
> of that.
>
> The best testing framework I've seen was for Forth,
> a language which shares
> many characteristics with Joy; it was simply four
> words: "testing", "{",
> "}", and "--". It was used like this:
>
> ...the definition of "+" deleted...
> testing Commutative properties of addition
> { 3 4 + 5 + -- 3 4 5 + + }
>
> Vary handy, very natural, and it ran at the same
> time as compilation -- the
> tests usually directly followed the word's
> definition.
>
> -Billy
>
We could do something like an assert:
[3 4 + 5 + 3 4 5 + + =] assert
This could be like 'i', but would generate an error if
the quotation didn't result in true. There could even
be a switch to turn the assert off (make it a pop) for
speed once the testing was done.
Ocie
__________________________________________________
Do You Yahoo!?
Buy the perfect holiday gifts at Yahoo! Shopping.
http://shopping.yahoo.com
Billy Tanksley — 2001-12-04 23:54:42
From: Ocie Mitchell [mailto:
ocie_mitchell@...]
>> testing Commutative properties of addition
>> { 3 4 + 5 + -- 3 4 5 + + }
>> Vary handy, very natural, and it ran at the same
>> time as compilation -- the
>> tests usually directly followed the word's
>> definition.
>We could do something like an assert:
>[3 4 + 5 + 3 4 5 + + =] assert
>This could be like 'i', but would generate an error if
>the quotation didn't result in true.
The Forth test is different, but still doable in Joy.
[3 4 + 5 +] [3 4 5 + +] assert_same_stack_effect
The implementation of same_stack_effect looks pretty simple -- run each
quotation on its own fresh, new stack (overflows are errors), and when both
are done, compare the resulting stacks. Error if no match.
>There could even
>be a switch to turn the assert off (make it a pop) for
>speed once the testing was done.
If we had the Forthish ability to run things at compile time, we wouldn't
need to turn it off --- we'd just include it in the file, as something to be
done at compile time.
>Ocie
-Billy
John Cowan — 2001-12-05 11:58:11
Billy Tanksley scripsit:
> The Forth test is different, but still doable in Joy.
>
> [3 4 + 5 +] [3 4 5 + +] assert_same_stack_effect
>
> The implementation of same_stack_effect looks pretty simple -- run each
> quotation on its own fresh, new stack (overflows are errors), and when both
> are done, compare the resulting stacks. Error if no match.
I don't see any way to implement this in the existing Joy1, primarily
because there is no place to keep the second quotation while we are
evaluating the first on a fresh stack. However, there may be a
combinator that can do the job -- I don't claim to understand them all.
--
John Cowan
http://www.ccil.org/~cowan cowan@...
Please leave your values | Check your assumptions. In fact,
at the front desk. | check your assumptions at the door.
--sign in Paris hotel | --Miles Vorkosigan
Louis Madon — 2001-12-05 12:48:29
On Wednesday, December 5, 2001, at 09:58 PM, John Cowan wrote:
> Billy Tanksley scripsit:
>
> > The Forth test is different, but still doable in Joy.
> >
> > [3 4 + 5 +] [3 4 5 + +] assert_same_stack_effect
> >
> > The implementation of same_stack_effect looks pretty simple -- run
> each
> > quotation on its own fresh, new stack (overflows are errors), and
> when both
> > are done, compare the resulting stacks. Error if no match.
>
> I don't see any way to implement this in the existing Joy1, primarily
> because there is no place to keep the second quotation while we are
> evaluating the first on a fresh stack. However, there may be a
> combinator that can do the job -- I don't claim to understand them all.
'infra' is that combinator:
assert_same_stack_effect == [[] swap infra] unary2 equal
Louis.
[Non-text portions of this message have been removed]
Louis Madon — 2001-12-05 12:54:52
On Wednesday, December 5, 2001, at 10:48 PM, Louis Madon wrote:
> ...
> 'infra' is that combinator:
>
>
> assert_same_stack_effect == [[] swap infra] unary2 equal
>
oops, this just defines a predicate, rather than raising an error if the
test failed, but I guess you get the idea ...
Louis.
[Non-text portions of this message have been removed]
Manfred von Thun — 2001-12-10 05:31:41
On Wed, 5 Dec 2001, Louis Madon wrote:
> On Wednesday, December 5, 2001, at 10:48 PM, Louis Madon wrote:
> > ...
> > 'infra' is that combinator:
> > assert_same_stack_effect == [[] swap infra] unary2 equal
> oops, this just defines a predicate, rather than raising an error if the
> test failed, but I guess you get the idea ...
Yes, your solution is correct. A more elaborate version:
assert_same_stack_effect == (* [P] [Q] *)
dup2 (* [P] [Q] [P] [Q] *)
[ [] swap infra ] unary2 (* [P] [Q] [P'] [Q'] *)
[ equal ] (* [P] [Q] T/F *)
[ pop pop ] (* *)
[ "Assertion failure:\n" putchars (* [P] [Q] *)
putln putln abort ] (* *)
ifte;
This keeps copies of the two quotations in case of assertion
failure, so that both can be output when that happens. If there
is no failure, the two copies are popped.
I find this style of commenting quite useful, and I am using
it more and more when designing programs on paper. Let me know
what you think.
- Manfred
Billy Tanksley — 2001-12-10 17:40:07
From: Manfred von Thun [mailto:
phimvt@...]
>assert_same_stack_effect == (* [P] [Q] *)
> dup2 (* [P] [Q] [P] [Q] *)
> [ [] swap infra ] unary2 (* [P] [Q] [P'] [Q'] *)
> [ equal ] (* [P] [Q] T/F *)
> [ pop pop ] (* *)
> [ "Assertion failure:\n" putchars (* [P] [Q] *)
> putln putln abort ] (* *)
> ifte;
>I find this style of commenting quite useful, and I am using
>it more and more when designing programs on paper. Let me know
>what you think.
Yes, it's a classic Forth style. I personally don't care for it, but it's
GREAT when designing.
The problem is twofold: first, it breaks up the stream-oriented
concatenative code so that it's hard to edit and wordwrap; and second, it
encourages programmers to write longer code. Here's a version which I would
be happier to release as a final product:
evaluate2 == (* [P] [Q] -- [resultP] [resultQ] *)
[ [] swap infra ] unary2;
same_stack_failure == (* [P] [Q] -- **ABORT** *)
"Assertion failure:\n" putchars
putln putln abort;
assert_same_stack_effect == (* [P] [Q] -- | **ABORT** *)
dup2
evaluate2
[ equal ]
[ pop2 ]
[ same_stack_failure ]
ifte;
Now, this makes me happier as a final result, but I admit that neither one
is easy to work with in ASCII; the manipulations you naturally do while
refactoring destroy the formatting in both. I think the only solution is to
have a good editor -- and my ultimate good editor would annotate the stack
effect of each line automatically, and if you hovered the mouse cursor over
a word it'd popup a stack derivation and draw little arrows pointing to the
sources of parameters for the words.
> - Manfred
-Billy
Heiko.Kuhrt@t-online.de — 2001-12-11 21:32:56
On Mon, 10 Dec 2001, Manfred von Thun wrote:
>...
>
> assert_same_stack_effect == (* [P] [Q] *)
> dup2 (* [P] [Q] [P] [Q] *)
> [ [] swap infra ] unary2 (* [P] [Q] [P'] [Q'] *)
> [ equal ] (* [P] [Q] T/F *)
> [ pop pop ] (* *)
> [ "Assertion failure:\n" putchars (* [P] [Q] *)
> putln putln abort ] (* *)
> ifte;
>
>...
>
> I find this style of commenting quite useful, and I am using
> it more and more when designing programs on paper. Let me know
> what you think.
I think it is great, especially for other people trying to understand what happens.
But it helps only as far as it's free of errors. The more comments there are
the more errors there are, too.
What I'm using is as follows:
assert_same_stack_effect ==
(** [P] [Q] *)
dup2
[ [] swap infra ] unary2
(** [P] [Q] [P'] [Q'] *)
[ equal ] [ pop pop ]
[ "Assertion failure:\n" putchars
putln putln abort ]
ifte;
(** *) causes my editor to produce a different syntax-highlighting style.
BTW, what about a comment like below, it could save a lot of typing:
assert_same_stack_effect == # [P] [Q]
dup2 # [P] [Q] [P] [Q]
[ [] swap infra ] unary2 # [P] [Q] [P'] [Q']
[ equal ] # [P] [Q] T/F
[ pop pop ] #
[ "Assertion failure:\n" putchars # [P] [Q]
putln putln abort ] #
ifte;
-Heiko