Re: [stack] impure concatenativity: let without translation

On Mar 19, 2008, at 6:02 PM, William Tanksley, Jr wrote:

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

Indeed. Of course lambdas can do a lot more than just shuffle.

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

Yes, we might imagine some wonderful macro system that has all sorts  
of hooks into the type checker and can inform it in various ways to  
allow it to somehow present code as it was written, preserving  
variable names and so on, when giving type errors. I don't think this  
is really possible in practice though without some massively  
complicated system and a truly heroic series of macros. Ultimately, I  
think it's a necessity for the type checker to be able to deal with  
let/lambda/etc if you're going to offer them.

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

Agreed. I don't dispute that this adds complexity to the semantics  
overall.

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

Compositing quotations is equivalent to composing functions. I see  
this as a necessity. In either case, I don't see how you can create  
closures without quoting values and composing functions.

>> 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 this the moment you introduce macros anyway. In either case,  
you only lose it if you use variables. If you don't use them, you're  
right where you were.

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

This ignores the possibility that lambdas might allow you to write  
code that doesn't put you in those situations as often to begin with.  
Variables are again only optional. Yes, you're stuck with them when  
looking at someone else's code, but no language is going to prevent  
programmers from writing terrible, confusing messes. I'm not a big fan  
of denying programmers powerful tools on the grounds that others might  
abuse them (not that that's what you were suggesting necessarily).

- John