Re: [stack] impure concatenativity: let without translation

On Mar 20, 2008, at 12:03 PM, William Tanksley, Jr wrote:

> John Nowak <[email protected]> wrote:
>>
>
>> I don't see why macros would complicate the type checker. Perhaps you
>> were suggesting that macros complicate concatenativity.
>
> I was replying to your message, in which you appear to be talking
> specifically about the problems of making the type checker emit
> reasonable error messages in the presence of a sophisticated macro
> system. Did you mean something else?

Ah, no, I didn't. I thought you were suggesting macros would make type  
inference itself more difficult, not simply the ability to report  
useful errors.

>> 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.
>
> I don't see why this is a limitation.

It's not; it's quite nice in fact. I was only pointing out that it  
isn't a general solution. You do need the ability to quote/compose in  
certain cases.

> We're dealing with largely imperative languages here; they're always
> going to be clearer when expressing algorithms than they are when
> expressing formulas.

Perhaps this shows a difference in our thinking here. I'm interested  
in making concatenative languages feel as declarative as possible. It  
seems to me that variables are necessary to achieve that in some cases.

>> 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.
>
> Either way, your work is very interesting. I don't know what an
> "effect system" is, by the way.

An effect system is what Haskell programmers wish they had, even if  
they don't know it. Such a system as it works in Fifth allows you to  
freely mix effectful and pure code however you wish. The effect system  
is powerful enough to sort out what you're doing and, with complete  
accuracy, tell you which functions are pure and which aren't. In the  
case of combinators, it can tell you which functions provided to the  
combinator must be pure in order for the total effect of using the  
combinator to be pure. If a programmer isn't at all interested in  
purity, they simply ignore the system.

The system can be used to enforce that certain functions are pure  
which is very useful when dealing with things like contracts, futures,  
map-reduce, et cetera. On the other hand, it allows free use of things  
like shared mutable arrays without them contaminating the rest of your  
code. Unlike the Haskell situation with monads, you don't run into all  
sorts of composability issues. See http://tinyurl.com/yvfhnf for some  
of Oleg's thoughts on this.

- John