Re: [stack] impure concatenativity: let without translation

On Mar 19, 2008, at 5:48 PM, rahul wrote:

> ....snip...
>> There is. Special forms and macros need access to the entire tree to
>> do their work. If you were to put 'define' at the end, then there's  
>> no
>> way for it to act on the tree (without some bizarre backtracking).
>
> Actually post script does:
> /inc3 { 3 add } def
>
> (and so does V :) )

This is a nice approach for a dynamically typed, late-binding  
language. If 'def' is just a procedure that takes a symbol and a  
quotation on the stack, you can do things like quote values on the  
stack and define them at runtime for later use. There are a number of  
nice tricks actually. All of the interpreters I've written for  
concatenative languages work like this.

Unfortunately, this approach doesn't work for a statically-typed,  
early-binding, compiled language. There are a number of reasons for  
this:

1. It is necessary to run the program in order to get the definitions.  
This is obviously massively complicates, well, everything really.

2. Type checking is awkward as you run into errors in the definition  
before you know what the definition will be named. Error reporting  
becomes more difficult.

3. There's no way to introduce recursive definitions as the recursive  
call needs to be resolved before the name of the function is known.

4. Tool support is largely out the window.

5. You can't ensure that type checking or compilation will ever  
terminate.

>> Keep in mind that even [a b c] is really (lambda () a b c). Putting
>> meta-level things like 'define' and 'let' up front also aids in
>> readability.
>
> not entirely. '[a b c]' is really '<quote literal> lambda' :)

The same issues described above apply here. This is actually even more  
problematic as there's no way to guarantee that you can statically  
resolve bindings.

- John