Re: [stack] stOck

What's my point ?
Well I've lost the OP's exact wording.
But HIS main point was that 'stack doesn't model the problem domain'.

Yes, but it models the problem solution method [algorithm] of
every 'entity which has evolved to have intentions'.
Which you obviously understood, since you gave the apparent
counter-example of a declarative language.
So yes, once I hand the task to google [or prolog], I skip stacking
that part of the task.
When google returns data I continue with the stacking process.

Interestingly [to me], Turing apparently saw the sequence of instructions
as being 'flat' [as a writer 'here' calls it]. But the concept of sub-routine
[chuncking] is so natural that abandoning it is absurd.

== Chris Glur.

PS. sorry about the crappy gmail posting
 facility !

PSS. I agree with the OP's idea of getting rid of stack shuffling.
It's the stacking/storeing that can't be bettered.
That's why I wrote stack/tree.


On 4/1/09, William Tanksley <[email protected]> wrote:
> 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
>
>
>