Joy, Lambdas, Combinators, Procedures
btanksley@hifn.com
btanksley@hifn.com
Fri, 28 Jan 2000 10:02:43 -0800
> From: iepos@tunes.org [mailto:iepos@tunes.org]
> > > 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