Re: [stack] stOck

Le Thu, 2 Apr 2009 00:50:45 +0300,
chris glur <[email protected]> s'exprima ainsi:

> 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'.

While I don't have a copy of that post at hand, it was actually only a paragraph in a rather long message. And I was not talking of the stack by itself, but of the stack juggling operations.
My point was that these operations do not map to anything in the model, or solution, as could be expressed using words, sketches, or other PLs. As such, I view them as annoyance and an unnecessary additional obstacle in the task of programming -- that is already a very difficult one, indeed.
This is personal opinion, for sure. It is based on the idea that a *good* programming language is one that lets one express as straightforwardly as possible one's "model" (meaning the way one views the problem to be solved, the system to be simulated, or whatever is the object of a programming task).

In the case of a stack, the data are stored in such a structure that it requires juggling in addition to operations that well belong to the operative solution. Compare this to iteration in a collection: In C or Pascal you need an index only because of (wrong) language design. In Python you can write "for item in collection:" directly, in Ruby "collection.each()", in Io "collection foreach ()", all idioms which imo better map the model.

> Yes, but it models the problem solution method [algorithm] of
> every 'entity which has evolved to have intentions'.

I do not see it like you. There is a distinction between stack use and data flow. I like very much the way concatenative languages allow expressing a program as a data *&* process flow. [This reminds me of automation programming languages' notion of "sequensor" (not sure of the word in english).]
Unless I misunderstand your point, your talking of the operative process and of the fact that concatenative languages express as a combination of functions/words. This can be seen as orthogonal to the data storage structure.

> 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.

That's much closer to the chunk of my original post you're citing!

Denis
------
la vita e estrany