# 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