Re: [stack] impure concatenativity: let without translation

On Apr 3, 2008, at 6:35 PM, William Tanksley, Jr wrote:

> second, <ironic>solving once and for
> all</ironic> the pesky problem of finding the roots of a quadratic
> equation in a concatenative language. I'll do the latter in a distinct
> post.

I look forward to it. I assume it's nicely doable even if I've not  
seen it done yet.

> <define>(quad a b c)
>    <let>
>        ...
>   </let>
>      p n
> </define>
>
> Such a syntax would be unbearable over short ranges (like in the 'let'
> above), but I suspect it would be convenient over large syntatic
> blocks -- and would make counting parentheses a thing of the past.

In all honesty, I've not ever counted parentheses since I began using  
DrScheme for all my Scheme editing needs years ago. I really do think  
this is a tool problem. For example, to give the benefits of what you  
show here, the editor could flash the name of the first element of  
each list as you close them. Mousing over a closing paren could do the  
same. I do think the current state of things though in DrScheme (and  
presumably emacs) is quite sufficient.

>> What are the negative practical implications of being impure?
>
> The problem is that we don't know. I'd like to understand the negative
> practical implications of being purely concatenative. I know they
> exist.

After working more on this recently, I've become convinced that having  
a concatenative language that is not *purely* concatenative is simply  
a horrible idea (macros and so on are fine). It complicates not only  
the implementation, but also how you can fundamentally reason about  
the language. Additionally, as you say, we simply don't know  
everything we'd be losing yet.

I've mentioned this before, but I believe such an argument possibly  
extends to recursive definitions as well (e.g. fact = [zero?] [succ]  
[pred dup pred fact *] if). To make a completely and wholly  
unconvincing argument, such definitions destroy the soundness of my  
termination checker. A special form like 'letrec' would do similarly.

At the moment, I'm going forward with a purely concatenative language  
that also does away with recursive definitions and is hence  
"nameless". In other words, there's no difference between a function  
definition and a (simple expanding) macro definition except in terms  
of implementation details (provided that quotations are opaque). I've  
posted a bit about this previously, and I'm now beginning to  
understand some of the implications with respect to the type system  
and optimization possibilities.

I don't think it should be surprising though that such a "restriction"  
helps reasoning; if the type system prevents an 'm' combinator in any  
form ('dup i'), then your recursive possibilities depend entirely on  
the combinator set you are given. You therefore only need to  
understand the fundamental properties of each combinator to understand  
the properties of a program as a whole. Any sort of indefinite looping  
would require use of an appropriate combinator (e.g. "while"). You can  
also take advantage of the situation to prove that a given function  
uses a bounded amount of stack (where functions involving 'linrec' or  
similar would not).

- John