# comments - 4

## phimvt@lurac.latrobe.edu.au — 2000-07-20 09:25:43

    There was a long thread (72 items) on the subject "joy applications".

    (Some of it drifted a bit, of course.) I'll comment on some ideas.

    1: "Variants of Forth, Joy, K ..."

        I would encourage experimentation in this area. I would recommend

    doing it in a very systematic way. Look at various separate issues

    (or issues that are _almost_ separable). A starting point may be the following:

        a) Composition of (stack-) functions  vs.  application

        b) Typing:  static (at compile time) vs. dynamic (run time)

                    monomorphic  vs.  polymorphic

        c) structured data:  arrays (vectors)  vs.  (linked) lists

            This will affect the language in many ways -

              what is reasonable to expect, implementation issues etc.

        d) the stack: array  vs.  list

            This is independent of c), but I suspect most designers would

            opt for the same method.

        e) code:  as data  vs.  inaccessible

            This is not quite as independent of a) as it should be.

        f) code as tree  vs. bytecode  vs.  threaded

             Again not as independent from a) and e) as one might wish.

        g) aims:  theoretical elegance vs. user efficiency  vs.

            machine efficiency.

    2: "Stack/concatenative/combinative languages"

        It would be terrific if some people could spell out principal

    differences between the languages that have been discussed here.

            Forth

            J       (am I right that it is a successor to Iverson's APL?)

            K       (successor of J?)

            Joy     (parthogenesis!)

    Such a discussion could also help to make the a)..g) list (above)

    more complete, and thereby help future designers.

    3: "absorbing the syntax of other languages"

        I have not attempted that at all in Joy. In fact it is almost

    certain to destroy the syntax-to-semantics homomorphism of Joy:

        "The meaning of the concatenation of two programs P and Q is

         the composition of the meanings of the two programs P and Q."

    (There are many ways of saying the same thing.) If this is to be

    retained then at best the syntax of another language with the same

    principle could be absorbed. That leaves only two possibilities:

    a) mere lexical absorption (e.g. drop == pop), or b) change the

    order of execution - left to right (in Joy) becomes right to left

    (prefix notation). I do not see anything gained.

        In Lisp of course many experienced programmers swear by macros

    and define-syntax and the like. Others say that it is all a bad

    idea since it makes code hard to read. Proponents argue that it

    makes things easier to read. I cannot enter the Lisp debate since

    I have written only one Lisp program (incidentally, it was a Joy

    interpreter).

        I should like to see how syntax of other languages is absorbed

    in Forth, and how it changes the readability of programs. If it

    really is a good idea, since Joy-program = Joy-data, it can be done

    in Joy. I want to know whether it should be done.

    4: "Arbitrarily complex expressions"

         This is a perennial problem. In languages in which one has

    named formal parameters, the names can be used to refer to the

    actual parameters. Joy can't do this, although one might extend

    Joy in that direction. (Question: am I right in believing that

    it is done quite often in Forth?) Consider a definition in a

    fantasy functional language:

       f(x,y,z) =

            g(h(x,j(y,x,z),k(z,l(z,y)),x)        (* I hope the parens are OK *)

    The point being that in the second line each of x,y,z occurs several

    times. The second line need not occur in a definition, but might be

    part of a larger (again!) expression. Question: how to do the same

    sort of thing when x,y,z are not available as names, and the actual

    parameters have to come from the stack.

        I doubt whether there is a really clean solution in Joy or

    (that fragment of) Forth without named formals. The same problem

    occurs in combinatory calculus (= lambda calculus minus abstraction

    plus parameter shuffling combinators). It is known that the two

    combinators S and K are sufficient _in the logical sense_, but

    resulting programs are totally unreadable. (See Church, Curry,

    Peyton Jones,..) Other combinators are often added, in particular

    two called PHI and PSY are useful, for applying a function to two

    arguments, or two functions to the same argument, and then applying

    the another function to the two results. One can go on and on

    inventing and implementing further parameter shuffling combinators,

    and each pattern (like the one above) can be given a name.

    (Brent's "sip" falls into this category.) And yet, often

    the pattern with x,y,z will be more readable than the name.

    I do not know an answer to all this - except to hope that

    perhaps in _real_ problems you don't get such complex patterns.