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

Have you written anything non-trivial with this system? Before you go
ahead and spend a lot of time using this formalism, I suggest you
write a few hundred lines of useful code, and run it in a simple
hacked-up interpreter if you don't have a full compiler yet. This will
show you how appropriate the system is for expressing the flow of data
elegantly.

Dan

> A concatenative-style FP-like language doesn't need shufflers. You can
> define them if you want, but they're not really useful. The trick, it
> seems to me, is to get rid of the stack and only enlist items when
> dealing with two or more. This is the trick to making construction
> (aka 'cleave') really useful.
>
> As an example, here's the definition of 'map' in a Joy-like language:
>
> map = [swap null?] [drop] [[uncons] dip [dip] keep map cons] ifte
>
> 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))])
>
> (Apologies if you're not using a monospace font.)
>
> Essentially, you make heavier use of a cleave-like form to add some
> useful "nesting" to the language.
>
> 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. 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]
>
> Not sure if this all makes sense. My point is this: Concatenative
> languages don't necessarily need shufflers. Only stack-based
> concatenative languages do.
>
> - John
>