Re: [stack] impure concatenativity: let without translation

On Mar 19, 2008, at 8:03 PM, William Tanksley, Jr wrote:

> I admit that it's entirely unproven whether an inferential static type
> checker can work at all in a concatenative language,

I swear I'm going to post that example soon...

> let alone one with macros.

I don't see why macros would complicate the type checker. Perhaps you  
were suggesting that macros complicate concatenativity.

>> 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.
>
> What do you mean "closures"? In my book, a closure is a function which
> refers to lexically available variables outside its local scope. A
> purely concatenative language does not have variables, and so does not
> have closures in that sense.

What I'm suggesting is code like this, where 'foo' is a function that  
takes an argument 'x' and returns a function with 'x' closed over:

    x foo = [bar x quux]

That would get translated to point-free code like this (assuming a  
clever translation mechanism):

    foo = quote [bar] swap compose [quux] compose

It seems that there's no way to do a proper translation of something  
like 'foo' without 'quote' and 'compose'.

> See http://factor-language.blogspot.com/2007/08/compiled-curry.html  
> for
> the obvious way to do partial application in Factor.

The obvious way to implement partial application is in terms of quote  
and compose:

    pa = [quote] dip compose

The Factor example seems to only avoid this when the function created  
via partial application is not returned from the context in which it  
was created.

>>> You lose the ability to refactor a function using only cut-and- 
>>> paste.
>>
>> You lose this the moment you introduce macros anyway.
>
> No, you only lose it over syntax macros, not expansion macros.

Fair enough. I was assuming a more powerful macro system.

> I do concede and admit that having more tools is more practical than
> having fewer tools, so including locals and lexical scoping is better
> than not doing so; the problem isn't the locals, but the fact that
> most programmers are trained in nothing but them, and use them as
> crutches for their own lack of understanding rather than as poles to
> vault over problems that are truly helped by them.

This is a good point, although I see this as more of a problem to be  
solved via education and community conventions than anything else  
really.

> (Problems such as the infamous quadratic formula. I'm preparing an  
> alternate, purely concatenative approach to that, one which is not  
> as pretty but has interesting features to it.)

Sometimes though, you just need something to work as quickly as  
possible. If your language requires that you sit down and ponder how  
to translate something like the quadratic formula, you have a problem.  
I'm not suggesting that you agree or disagree with this; just stating  
my opinion.

> Concatenative languages are in their infancy.

This is a very, very good point. I'm experimenting with one particular  
aspect of concatenative languages; that is, placing them into a typed  
context. Alternatively, I'm experimenting with effect systems and type  
systems in a concatenative context if you'd prefer to put it that way.

There's so much that I'm necessarily ignoring to be able to focus on  
these things. I'm still very interested in the purely concatenative  
approach as a way of writing simple, concise programs in a highly  
simplified language. The language I'm working on is not that language;  
I'm trying to convince myself to focus on just one for the moment.

- John