RE: Joy, Lambdas, Combinators, Procedures

> From: iepos@xxxxxxxxx [mailto:iepos@xxxxxxxxx]

> > > Well.. The meaning Joy associates with "3" is slightly different
> > > from the ordinary English meaning of "three".
> > > That the meaning differs may make it a 
> > > little harder to read and write programs, but this is 
> > > probably a matter of taste.

> > Good grief, no!  Didn't you read the manuals?  Joy has 
> > problems, but it's
> > _certainly_ not this one!  Programs in Joy are generally 
> > *dramatically*
> > easier to understand (that is, realize what proofs are 
> > implied) and even to
> > prove things about.

> Well, I suppose Joy programs, once you get used to them, are easier
> to understand than similar programs written in C, for example.

"Damning with faint praise."  ;-)

> What I meant was that I'm not convinced that Joy programs are
> easier to understand than similar programs written in a
> purely functional language.

First of all, please realize that Joy is a purely functional language.  I
think you mean "a more traditional purely functional language."

Read the docs for examples of why this is not obviously true.

> But again, how "easy" a program  is to understand 
> varies from person to person.

Correct -- which is why I provided the parenthesis, defining "understand" as
"realize what proofs are implied."  Crummy definition, I know.  I meant
something slightly different from what I said, and I don't know how to say
it right.

Perhaps by "understand" I mean "realize that the program visibly implements
a proven concept."

> We could talk about program size;
> I suspect that most programs written in Joy could be written in
> as a functional program of similar size, but I can't really
> support this, because I don't know of any functional language
> that is as good as Joy (there may well be one somewhere, and I believe
> one could be constructed).

Joy is a functional language.

> > > Anyway, I find Joy to be quite an interesting system. But,
> > > I don't know that its approach of using composition and quotation
> > > is fundamentally superior to a purely applicative approach.

> > Read the manuals -- it's so clearly superior it's not even funny.

> I've read most of the synopsis pages, but I'm not convinced.

You need to actually see him work some proofs using Joy as a notation.  It's
quite impressive.

> (i've tried to get the interpreter working, but it won't compile
> correctly on my machine). Anyway, I'm not going to seriously
> claim that a purely applicative approach is better than (or even as
> good as) the Joy (stack) approach either until I find or make a good 
> functional system. 

> Remember that by "a good functional system" I do not mean one that
> requires (or even allows) the use of variables in forming functions;
> the kind of system I'm thinking of would use combinators,
> similar to "dup", "swap", and "pop", to form them.

There are two systems I know of which use combinators efficiently and
thoroughly: Joy/Forth and J/APL.  In both cases, the RPN systems have more
of a dependance on explicit combinators; the APL systems imply theirs (and J
has some really funky implied combinators, with its "hook" and "fork"
combinations).

> - "iepos" (Brent Kerby)

-Billy