Re: [stack] Barebone implementation of concatenative language in c or c++

On 05/18/2010 02:42 PM, John Cowan wrote:

> If you consider it a problem.  I consider it one of Joy's special beauties:
> the abstraction for a sequence of datums is the same as the abstraction for
> a non-primitive function, which is just a sequence of functions.

Sure, it's simple, but what's beautiful about it? It's a bit like having 
Scheme without lambda really. I believe Pico Lisp takes an approach 
similar to this, but no other Lisp I've aware of does, and for good 
reason. If given the choice between a language with the ability to 
construct abstractions and one without, all other things being equal, 
I'm certainly opting for the former. I can't think of an instance where 
I wouldn't.

>> Finally, applicative languages arguably have an advantage over Joy in
>> terms of arbitrary order reduction. For example, take this Haskell
>> function:
>
> I don't think your example has anything to do with applicativeness, but
> with purity and laziness.  A pure lazy concatenative language would have
> the same strengths (and weaknesses) as Haskell.

Perhaps I've made my point poorly. I'm actually pointing at the lack of 
many nice algebraic laws in Joy precisely because Joy is concatenative. 
Laziness has nothing to do with it. Look at my example again:

   Haskell:  bi f g x = (f x, g x)
   Joy:      x [F] [G] bi = x F x G

The issue is that the 'bi' in Haskell always permits arbitrary order 
reduction whereas determining if it is possible in the Joy version is 
undecidable. This is true regardless of concerns related to strictness.

This is a general problem with Joy. For example, the following law holds 
in Haskell:

   map f . map g  ==  map (f . g)

However, the following does *not* hold in Joy:

   [F] map [G] map  ==  [F G] map
   (where [F] map = [null?] [] [uncons [F] dip [F] map cons] ifte)

Similar issues hold for other functions like fold. The source of the 
problem is the fact that all functions in Joy are lifted to operate on 
products (i.e. the stack). This makes it difficult or impossible to 
write higher order functions that have the usual laws because it is 
difficult or impossible to prevent functions from accessing arbitrary 
amounts of the program's state. For example, the above law for map does 
hold with the side condition that 'F' has a stack effect of ( x -- y ).

Manfred's "The Algebra of Joy" talks about Joy's suitability for 
equational reasoning and algebraic manipulation, but I'm of the opinion 
that it's not actually very good in this regard. I'd actually say that 
languages like Clean or Haskell -- or better yet, something like 
Charity, Squiggol, or Hagino's CPL -- are far better in this regard. 
This is doubly true since Joy offers no control over effects.

This is not to say that Joy is not interesting is other ways of course. 
However, I'm of the opinion nowadays that it fails in its (primary?) 
objective of providing simple and powerful algebraic manipulation. It's 
for this reason that I've generally lost interest in concatenative 
languages.

Please correct me if I'm wrong on any of my points.

- jn