# comments - 9

## phimvt@lurac.latrobe.edu.au — 2000-08-03 11:11:28

    1. "swap23"

        Indeed, swap23 == swapd == [swap] dip. I am in two minds about

    notation here: on the one hand swap23 is nice because it shows

    what is to be swapped, whereas swapd is nice in analogy with

    popd and dupd. Thanks for pointing out the missing definition

    (and also the inconsistency concerning "times" in the papers

    and the manual). MUST FIX.

    2. "The order of arguments"

        I was not persuaded by the argument that  5 3 -  ==>  -2

    "because [3 -] is the program which subtracts the item on top

    of the stack from 3".

        Surely the justification must also work for larger examples, e.g.

           3 4 * 2 3 * -

    Here one cannot argue that [... -] is the program which subtracts the

    item on top of the stack from ... . It would not work for any of

    the possibilities for ... , as follows:

            [* -] cannot be the program which subtracts the item on the

    top of the stack from * because multiplication is a binary operation,

    and you cannot subtract anything from it.

            [3 * -] cannot be the program which subtracts the item on the

    top of the stack from  3 *  because  3 * is at best a unary operation.

            [2 3 * -] cannot be the program which subtracts the item on

    the top of the stack from 2 3 * because, and I am less certain of this,

    to even evaluate 2 3 * the top of the stack must have been used already.

        I think there are good reasons to stick to conventional order

    of operands. Then the translation from infix to either prefix or postfix

    will retain the order of operands but shuffle only operators.

        Maybe I am quite wrong in what I just said. But I would ask this:

    what is the reason for wanting to make  [3 -] the program which

    subtracts the item on top of the stack from 3 ?  (I suspect that

    such reason would go back to a rather good one by Iverson on APL.)

    3 "conk manual"

        I am impressed by the way conk seems to be growing. I think that

    the language is sufficiently different from Joy that _in general_

    any argument for doing things one way in Joy is not necessarily

    an argument for doing it that way in conk - and vice versa. So

    do not apply my reasoning below (for Joy) directly to conk,

    but experiment freely with all sorts of different things,

    and look at the arguments as they apply to conk.

        There was some discussion about evaluated and unevaluated quo-

    tations. The unevaluated quotation

                [ [2 2 +] [3 4 -] ]

    can be evaluated by  [i] map  to give the evaluated quotation [4 -1].

    Or it can be evaluated by  [i [] cons] map  to give  [ [4] [-1] ].

    A mixed quotation can be selectively evaluated as required. Consider

       [ [[2 3 +][2 3 *]] [[3 4 +][3 4 *]] ]

    Suppose we want, in each pair, to evaluate the second (the *) but not

    the first (the +). This will do it:

       [uncons first i [] cons cons]  map

    to give

       [ [[2 3 +]      6] [[3 4 +]    12] ]

    And if you want the 6 and the 12 inside [] that is just as easy.

    I do not know whether the need for partially evaluated lists arises

    much in practise (I do live in an ivory tower).

        In Joy the program

                  2  3  [+]  first

    leaves three items on the stack, the + topmost. If you want to use

    the + to add the two numbers below, then you must use this:

                 []  cons  i          OR         unitlist  i

    The need for putting + on top of the stack, or for executing

    and operator on top of the stack, does not seem to arise much

    in ordinary programming.

        On the other hand, such a facility it is necessary for the Joy-in-Joy

    interpreter, the requirement that one be able to write an interpreter

    for the language in itself. Compare that with Lisp-in-Lisp, which

    many of the early books on Lisp used to include. Are there

    any plans to at least enable a Conk-in-Conk to be written ?

        If it is really necessary to get operators on top of

    the stack quite frequently, I would not be too stronly opposed

    to say a backquote, as was suggested:

                  2  3  `+

    to get the bare + on top of the stack. I would not be opposed to

    allow an operator, say i1 == unitlist i.  But one would want to

    distinguish i from i1 because their behaviour would have to

    differ for the case where what on top of the stack is a quotation,

    say [3 4 *]. Here i would execute it to leave 20, and i1 would

    execute its unitlist to leave the original three part quotation.

       Further on in that thread there was some discussion on what

    function types really are, and Louis presented some results in the

    case of Joy (thanks, I had not thought about those). He also

    says what many books tell you: all one can do with a function is

    to apply it. This isn't quite true, of course. You can also

    compose functions:  fog  =def lambda x: f(g(x)) in the case of

    unary functions, and many (too many) possibilities for functions

    of more then one argument. As the stack oriented languages

    show, the n-ary or polyadic functions can all be implemented

    as unary stack functions. But now even "123" denotes a unary

    stack function - the one that takes a stack as argument and

    returns another stack with the number 123 (no quotes here)

    pushed on top. Very often we are interested in this function

    denoted by "123", because of the one-one correspondence between

    integers and such integer-pushing functions. Put another way,

    which helps psychologically, I think, we pretend that we

    can make "123" mean either the number or the function, as the

    mood may take us.

       It seems I will catch up with the backlog of concatenative

    email eventually. I hope that thereafter I'll be able to

    respond not quite so synoptically (is this an adverb?).

        - Manfred