Re: [stack] stOck

chris glur wrote:
> WT wrote:-
> > have you looked at Factor's support for the
> > spread/cleave combinator set?
> I'm don't want to open another canOworms ?
> Unless it could have been explained in lines < 2,
> instead of 'go & get it', it's no good.

This is programming. To program you have to tell the computer *exactly*
what to do. If it can be explained in 2 lines, it's not programming;
it's something else.

I do think it's reasonable to ask for a 2-line motivation, so you can
know WHY you're looking at whatever library I just mentioned.

Here ya go :-): "Factor's spread/cleave/apply combinators allow one to
express one's intentions about dataflow rather than having to code in
terms of stack shuffling."

> == Chris Glur.
> PS. stacking doesn't hope to map to the problem domain.
> It DOES map to how any task is done.

This was very hard to understand. After much thought, I think I might
know what you're saying: you're pointing out that a problem isn't a
process, but rather an undesired state of affairs. It's therefore not
really apt to speak of coding in the problem domain, because (at least
in concatenative languages) we're not expressing the problem, but rather
a process which is designed to convert the initial state of affairs into
the final, desired state of affairs.

(I should mention that languages like Prolog actually do allow one to
code in the problem domain, by the definition I assumed above... Look
around for explanations of "declarative programming languages".)

> All tasks can/are decomposed heirarchically.

Okay, I suppose that they can. Certainly that's a feature of
concatenative languages.

What's your point?

-Wm