[stack] stOck

[Sean: thought you may be interested.]

Hello concatenators,

I would like to exchange about possible drawbacks of a data stack and a weird idea on a possible replacement. Maybe all of this is not new, sorry if ever, but I could not find references.

I am fully aware that stack juggling often seems mentally difficult basically because we are not used to it. If we had learnt arithmetics with postfix syntax then probably (1+2*3) would read alien. This point is not part of the issues discussed here. Instead, I think that:

* Naming, when carefully done, is an invaluable help to clarity.
* Stack operations (swap, dup...) do not mean anything about the mental 'model'.

About the latter remark: I think that a good program is one that mirrors the 'model' it expresses. Stack operations do not map to anything in the model (about the problem); instead they are only needed because of the stack limitations as a data structure. In other words, the choice of a stack to pass data from func to func introduces low-level code -- as opposed to high-level languages. Without any advantage of low-level languages, I guess (for instance _this_ does not help  programming closer to the machine).

Let us imagine a "stOck" instead of a stack ;-); that could be a hash/map/dict, meaning that items are named. Then we get the following advantages:
* naming
* no stack juggling
* no dup

For illustration, say we want to compute
	c * (a+b) / (a-b)

	:result (c b a -- result) + a b - / *

or using only names
	:result (c b a -- result) a b + a b - / c *

Note that this is different of environment or world state variables -- that live outside the stack/stock. To keep more advantages and properties of a stack-based process and data flow, especially that items are consumed when read, I thought at having a func-local temporary dict able to hold copies of used stock items. More precisely, when a stock item is read, then it is erased as usual, like with stack pop, but a copy can still live in the func's scope. The copy dict may hold:
* Brutally, a copy of the whole stock.
* Items used in the func.
* Only tems used more than once in the func.
I think this is rather easy to implement, both for interpreted and compiled languages: a common operation at start of every func.

As a side-effect, this would also let postfix syntax and concatenation much more appealing to people used to other paradigms, *especially in difficult cases*.

I think that it is possible to design a data structure able to act both as a stack and a dict (the reason why I choose 'stock', not 'dict'). Unnamed items would be read and used as usual. An alternative can be that unnamed items silently get an index instead - but then we need a syntax like eg '#n' to denote them.

Remains the question of naming: how do we concretely bind names to items? I thought the format used to name funcs can be reused -- provided a token marks the end of a func def (eg ';' or LF). The simple rule may be that the name is bound to the current result -- that probably should remain on the stack:

:func op op op :x op op...
(where 'op' denotes any possible term)

These ideas are partly inspired by Raven: http://aerosuidae.net/raven.html. I would enjoy comments and critics; especially about how such ideas fit the concatenative way.

Denis
------
la vita e estrany