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