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

John Nowak <[email protected]> wrote:
> 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.

I also don't like how Joy uses the same notation for list literals as
it does for function literals. Other concatenative languages don't do
this. I don't understand the rest of your response, in particular the
part about not being able to construct abstractions which seems so
important to you.

>>> 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.

No. The parallel evaluation laws don't apply because concatenative
languages are not tree-structured. The laws that apply are
_different_. You can't criticize Greek because it doesn't use a roman
alphabet -- although you could criticize ancient Egyptian for not
using an alphabet at all, and English because it uses an overly
complex phonetic system. Anyhow, before this set of criticism begins,
you have to justly characterize the algebraic laws that DO apply,
rather than mourning the ones that obviously do NOT.

> Laziness has nothing to do with it. Look at my example again:

Laziness is one of the things that can't easily be imported to a
concatenative language.

> 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.

In Joy it's undecidable. In Haskell it's decidable. The distinction
between the two isn't that one is concatenative and the other is
applicative; it's that Haskell's type system is designed to allow this
kind of decision, while Joy isn't. There are concatenative languages
which make deciding this linear in the size of the function
(StrongForth, for example).

> - jn

-Wm