Re: [stack] What does "concatenative" actually mean?

On Mar 3, 2009, at 3:57 PM, John Cowan wrote:

> John Nowak scripsit:
>
>> The easiest way to do it would be to pass a "world value" into the
>> program and then use uniqueness types to ensure no I/O actions are
>> performed when there exists more than one reference to the world
>> value. In this approach, you'd have to manually plumb the world state
>> around instead of using monads.
>
> That's what Clean does, correct?

Yes. The 'Start' function in your program makes this clear on the type  
level:

    Start :: *World -> *World
    Start world = startIO NDI Void initialise [] world

In my personal opinion, the monadic approach in Haskell is much  
cleaner. I'd still like to see uniqueness types added to Haskell  
though for things like destructive array update; I find uniqueness  
types preferable to monads in such cases. (Well, really, I just want  
to see Disciple Haskell become usable.)

In a concatenative language, one thing you can do as add the 'world'  
to the top of the stack and have all operations work below it except  
those that perform IO. This does let you sort of hand-wave and claim  
the language is purely functional. The problem is that *everything*  
now has a forced evaluation order, not just those things that perform  
IO. In other words, even though your language is purely functional,  
you're still essentially stuck with having to use eager evaluation.  
This is why I claim this approach is mostly hand-waving; it doesn't  
let you do anything different than you otherwise would.

Ideally, you'd handle the world value explicitly; this would make it  
clear which things can be reduced in an arbitrary order and which  
things cannot. You'd need to add a type system to ensure you don't  
violate assumptions about how the world value is used however. If you  
were allowed to duplicate the world value (or put it in an aggregate  
and then duplicate the aggregate), bad things would happen.

- John