Re: [stack] impure concatenativity: let without translation

John Nowak <[email protected]> wrote:
>  translate it to. Basic operations like 'swap' are defined in terms of
>  'lambda', not the other way around.

I have proposed using stackshuffles instead of stack operators.
Lambdas take that a little too far, though; a stack operator or a
stack shuffle works in at worst constant time; a lambda may never
terminate, and it's impossible in principle to tell.

>  The result is significantly better error reporting,

Only when you have a macro language laid on top of the base language
and the macro language has inadequate error reporting.

> a reduction in
>  complexity on some level (you don't have to reduce things to the point-
>  free translation to reason about them as 'lambda' is a fundamental
>  part of the semantics),

Point-free is reducible to atomic components. Lambda is not. That's
not a reduction in complexity "on some level".

> and a more efficient implementation (as you
>  don't have to quote values and compose quotations together at runtime
>  to create closures -- the implementor can choose whichever approach is
>  best).

I do agree that composing quotations shouldn't be necessary; but
indeed, it never was considered as such until Joy came along. More
power to Joy, but it's still only a convenience to be SOMETIMES used,
not a requirement.

>  Yes, you lose some interesting theoretical properties by defining the
>  language as such. I don't think any of these are of practical concern,
>  although if you can think of any, I'd be interesting in hearing them.
>  It seems all of the (minor) additional complexity would be born by the
>  implementor.

You lose the ability to refactor a function using only cut-and-paste.
You lose the ability to reason about a program in chunks as small as
you want (that is, in a concatenative language if you see a phrase
whose meaning you don't grasp you can work with that phrase in
isolation, and you can be sure that the phrase in context means the
exact same thing).

Add variables, and you have to think about the program in the same way
the author thought about it.

>  - John

-Wm