Joy, Lambdas, Combinators, Procedures

[btanksley@hifn.com]

> From: iepos@tunes.org [mailto:iepos@tunes.org]

> It's been awhile since I've made any comments to this list,
> so now I'm posting some of my thoughts...

Welcome back :-).

> A while back, some TUNES-sters expressed admiration for
> the Joy programming system. Although the current implementation
> seems inadequate for serious practical use, it does have some
> interesting features.

Right.

> In particular, Joy is nice in that it does not require one to
> use variables or anything like them. Instead, one uses
> primitive programs which they call "combinators" (which are
> similar to combinators in the ordinary sense).

Of course, this is not the advantage, but rather the means for the
advantage.

> One thing about Joy which bothers me is that it gives no way
> to formally express, for example, the number "2". Although it
> is possible to express the _program_ that "pushes the number 2
> onto the stack" (such a program is expressed simply as "2"), the
> number 2 itself cannot be represented. 

Okay, I admit it -- I'm completely and utterly lost.  What are you talking
about?  The symbol 2 represents the number 2.

The rest of your post discusses some of the ways you represent numbers in
your system, but doesn't serve to reduce my confusion one whit.

> This is a defect that seems fairly serious to me, although I suspect
> that it may be possible to fix the defect by reformalizing
> the interpretation of the system (perhaps eliminating the "stack")
> without changing how the system actually works.

This sounds like one of the posts we in comp.lang.python get every year
which demands that we improve Python by removing its "nasty whitespace
dependancy."  Of course, I know I've only misunderstood you.

> Anyhow, enough about Joy... now I'll describe some ideas I've had
> for a programming system, if anyone is interested...

Cool.

> In the system I'm thinking of, things would be expressed using
> purely applicative expressions (with mild syntactic sugar).

Nothing new there.

> That is, the system would supply some primitives (mostly functions),
> and then other things could be expressed in terms of these
> primitives using function application. Composition can be
> expressed using the "B" combinator, which will probably be
> taken as a primitive.

Okay.

> Only a single-parametered function application is necessary,
> of course, since multiple-parametered functions can be emulated
> using single-parametered curried ones (i.e., functions that return
> functions).

Like all the other languages.

>   put "hello" (wait 1 (put "world" stop))

> This seems to require a "stop" primitive.

'stop' is a very bad name -- 'nil' might be better.

> Anyhow, this is probably not
> really a new idea.

What is different about it?  It seems the same as all the other functional
languages.

> In a system that uses this technique, it would be
> important to distinguish between procedures, like
>   put "hello"
> and procedure completions, as one might call them, like
>   put "hello" stop

That makes a lot of sense.

I'm out of time, so I'll have to ask more questions later.

> Anyway, enough rambling... As usual there is my recently updated
> site on TUNES at
>  http://www.tunes.org/~iepos
> which I humbly proclaim as the Best source of introductory
> information on combinators (that I know of).

Really!  I'll have to check it out.  It'll have to be really good to
overpower both Joy and "The Forth shall be First".

> - "iepos" (Brent Kerby)

-Billy