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.