Re: [stack] Advantages of cat, joy ..?

John Nowak wrote:
> William Tanksley wrote:
> And here's the same thing in an FP-like language. You read right to  
> left instead of left to right. 'a' is defined as 'head' and 'b' is  
> defined as 'head tail'. Parentheses are cleave and brackets are  
> quotation:
>     map = if([null? a],
>              [a],
>              [cons(i(head a, b),
>                    map(tail a, b))])

This looks very much like an applicative language with optional
parentheses for single-argument functions.

> Essentially, you make heavier use of a cleave-like form to add some  
> useful "nesting" to the language.

I agree with the concept of adding nesting to express forms; but I don't
see the form in this case.

> I'm pretty sold on the FP-style approach at this point. I find it much  
> easier to work with than dealing with a stack and it retains all of  
> the properties I'm after.

My understanding is that "an FP approach" (function-level programming)
works very well with a stack, so I'm not particularly enlightened on
what this means.

> I do, however, prefer a first-order approach  
> with compile-time substitution for functions. Some additional syntax  
> for conditionals is also useful. For example:
>     map[F] = null? -> id; cons[F head, map[F] tail]

Here you're clearly defining an adverb, and your language doesn't allow
functions to be passed on the stack. I like this, but once again, this
isn't an example of a concatenative language without a stack, because
there's no concatenation happening.

> Not sure if this all makes sense. My point is this: Concatenative  
> languages don't necessarily need shufflers. Only stack-based  
> concatenative languages do.

You haven't offered an example of a concatenative language without
shufflers. Your best approach was (in the wikipedia thread):

a = hd
b = hd tl
c = hd tl tl
hypot = sqrt + [sq a, sq b]

...the problem is that in this language even this trivial example
requires the 'hd' and 'tl' shufflers.

Nonetheless I'm starting to see your point in this language, I think.
Every function takes and produces one datum, which is a tuple.
Meanwhile, a literal tuple is also a function of one argument, and that
argument will be passed to all of the components of the list.

Conceptually, the big difference between this and a stack-based language
-- if I'm reading it correctly -- is that this language uses a data tree
rather than a data stack. That's fascinating!

So how do nodes of this tree get constructed? I can see that once
they're constructed your language can pass them around and generate new
trees (or, equivalently, mutate the existing tree), but I don't see how
to express a cons.

> - John

-Wm