Re: [stack] impure concatenativity: let without translation

On Mar 19, 2008, at 4:31 PM, Daniel Ehrenberg wrote:

>> Are there any other proposals for an impure (or, more nicely,
>> "hybrid") concatenative language out there? What are the negative
>> practical implications of being impure?
>>
>
> I don't understand why you say this is without translation. Of course
> translation exists at some level; you're just proposing that it
> happens at a level that the user not see, and that the translation be
> tightly integrated into the development environment so that type
> errors and such are easier to read.

No, I'm proposing that there be no translation. (Or rather, if there  
is any translation, it would be something entirely up to the compiler  
author.)

In other words, I'm extending the core language by making 'lambda' a  
fundamental component of the language. This is the reason you can  
write '(lambda (a b) b a)' without needing some built-in 'swap'  
primitive (or something equivalent using auxiliary stacks, etc) to  
translate it to. Basic operations like 'swap' are defined in terms of  
'lambda', not the other way around.

The result is significantly better 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), 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).

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.

- John