On Mar 4, 2009, at 4:59 PM, William Tanksley wrote:
> I'm often overly impatient about figuring it out -- that makes me say
> things like "the stack is a monad, concatenative languages need
> else." I'm wrong to say that; it's more complicated than that. But a
> naive concatenative language (i.e. one that executes strictly in
> needs nothing else; and a sophisticated one needs only as much
> sophistication as its out-of-order execution can handle.
You're right, but I don't think this applies just to concatenative
languages. I may be misunderstanding what you're saying, but let me
clarify my point anyway.
Take the Scheme expression '(+ (+ 1 2) (+ 2 3))'. Instead of '()'
meaning application, we'll have it form a function that, when applied
to a world value, returns a tuple of a new world value and the result
of the expression. To reduce within a function formed by '()', the
function receiving the world would pass it to the left-most '()'
within it, get the tuple of the world and result back, save the
result, and pass the world to the next '()' within it. At the top
level of our program, we'll apply our function to the world value to
kick things off.
What I'm trying to say is that, with a bit of hand-waving, you can
make any language "purely functional" just by describing how the world
value would be threaded through the application. It should be obvious
though that this isn't particularly useful if it lets us claim that,
say, C is purely functional (which it would).
Threading a world value around is only useful if you *don't* pass it
to everything. The functions that don't need it can be evaluated and
reasoned about without caring about it.
You are 100% right that the monadic nature of concatenative code makes
linearity easier. Henry Baker would certainly agree. I think it also
may have the potential to make Haskell-style monadic code more natural
thanks to the left-to-right syntax.
I'm not even sure if I'm disagreeing with you; I just think we should
probably be a bit more careful with our claims. I'm certainly included
in that "we". In fact, I may have made some bogus claims related to
this very topic not so long ago.
> Joy is supposed to be somewhat functional -- if von Thun had
> intended it
> to be purely functional he would have done something different with
Manfred von Thun has, as far as I know, always claimed that Joy is
purely functional. Numerous articles on the Joy site make this claim,
the Wikipedia article for Joy makes this claim, et cetera. After
giving this some thought, I really do think it is misleading. Perhaps
Manfred meant to exclude IO from him claim; I've seen some evidence
for this, namely in the interview on NSL, but I don't want to guess at
> I entirely agree; that's why it's essential to maintain a distinction
> between "purely functional" and "purely concatenative". You can have
> both, neither, or either. There are benefits and prices for all
I completely agree with your distinction.
>> I feel that being able to evaluate in any order without worrying
>> side effects is somehow "more concatenative" than having to evaluate
>> left to right. Rather than make a claim here, I tried to sidestep the
>> issue to avoid contention.
> I'd disagree that it's more concatenative to be able to evaluate in
> order. It is certainly more functional (or declarative), though. And
> there IS value to it. The problem is that there's also a price to be
> paid, and not every programmer wants to pay it.
Again, I agree. This is a good way of breaking down the situation.