FW: Joy, Lambdas, Combinators, Procedures

[btanksley@hifn.com]

iepos asked that I forward this to the list -- he hit the wrong button and
replied directly to me rather than the list.

Again, I'd like to ask that this list set the Reply-to so that this doesn't
happen so often.  It's stupid.

-----Original Message-----
From: iepos@tunes.org [mailto:iepos@tunes.org] 
Sent: Friday, January 28, 2000 5:25 PM
To: btanksley@hifn.com
Subject: Re: Joy, Lambdas, Combinators, Procedures


> > Again, by "functional language" i meant "purely applicative language".
> 
> What do you mean, then?  All modern functional languages, and most of the
> early ones as well, are applicative.  

Eh? Hmm, Haskell, for example, is not purely applicative. It has
a lambda construct, and also a strange (pattern-matching) definition
construct. This is along with its strange constructs that involve
types. These constructs, it seems, are not syntactic sugar, but
essential constructs to the system.

In case this was not clear, by "purely applicative language", I mean
a language in which all expressions are built from a finite set
of primitives using a binary construct ("function application").
An expression in such a language is most naturally written
using a binary tree, with primitives as leafs. Of course,
expressions are written using strings, with parentheses (or separators)
to indicate the tree structure.

> It's one of the most thoroughly
> studied areas of computer science.  The benefits are very well-known --
but
> the drawbacks are as well.

Hmm, what drawbacks are you speaking of?

Anyway, one clear benefit of using a purely applicative language
is that it has such an amazingly simple syntax. In fact, the
syntax of a purely applicative language is simpler than the syntax
of a Joy-style expression. The essential construct of Joy is
the list ("quoted program"); the other constructs (such as the
finite-set construct and number-literal construct) could be eliminated. 
So, the format of a Joy expression is a tree (with primitives at the leafs),

> > maybe so... I believe proofs about a purely applicative system
> > may also be impressive. 
> 
> Impressive, yes -- but only in the sense of baroque complexity and limited
> applicability.  Really; I've seen hundreds of them.

I only suggested that there _exists_ (in an abstract sense) a
purely applicative system that is easy to reason about;
that you've seen hundreds of example bad systems does
not eliminate that possibility that there is a good one.
Anyway, can you give me one of those hundred examples?

> > Hmm... I've never heard of "J" or "APL"...
> 
> Oh no!  APL's a great system, lots of fun.  I recommend you start by
> learning J, since it uses ASCII characters (instead of APL's character
set,
> which requires not only extra characters, but even depends on being able
to
> overstrike them).  APL itself is a good language, but it's hard to learn
> without a special keyboard (IMO).

I might have to check it out, then... is there a freely
available system?

> K is a more recent derivative, but it's less APL-like, so I don't think
it's
> interesting to learn for the same reason I'm not interested in helping to
> write yet another applicative functional language ;-).

8-|

> > anyway, I see no point in arguing further over which kind of system
> > is better (Joy-style or purely applicative); I haven't really
> > claimed that either kind is generally better... but purely applicative
> > seems worth trying well, at least.
> 
> It's been tried thousands of times.  Look at _any_ functional language
aside

Can you give an example?

> from Joy.  Consider especially the ones with implicit currying; those have
> implicit application, which makes them more comparable to Joy's implicit
> composition.

(?)

> > - "iepos" (Brent Kerby)
> 
> -Billy
> 

- "iepos" (Brent Kerby)