Re: [stack] stOck

spir wrote: 
> William Tanksley <[email protected]> s'exprima ainsi:
> Exactly. Except I proposed instead a kind of mixed stack-dict. But the
> principle is well what you express -- and implementing with a stack
> and a dict is easier. 

Sorry, I don't know what "mixed" means in this context.

If you mean that the data is actually stored on the stack, that won't
work at all -- it's been tried in Forth, and it results in the stack
becoming useless whenever anything's put into the dictionary. You can't
even use 'swap' if the top item is named.

If you mean that the data's not stored on the stack, then what do you
mean by "mixed"? Later on you indicate that each word may have its own
local dict, in which case how can that even _possibly_ be associated
with the data stack (of which there's only one)?

What _did_ you mean?

> > Bindings in that dictionary are created by some means (you don't give an
> > example), and are destroyed after their first use (I'm assuming that's
> > what you mean when you say "the data items that will be deleted when
> > used in a func").

> I proposed in fact to reuse the existing syntax for naming
> functions/words. For instance 
> 	:word 1 + :name 2 * :result 

Ah. Here's the source of my confusion -- you said "existing syntax", but
you didn't explain what language you were borrowing the "existing
syntax" from. I don't know any language that uses a preceding inflecting
colon to define words (Forth uses a colon, but it's a word in its own
right, not an inflection).

But that's a fine syntax, no problem. Now I understand your proposal.

> > So a function might start like this:
> > : quadratic ( a b c -- )#( -- root root2 discriminant )
> >   ...
> > ;
> Nice ;-)

I'm not sure I'm "sold", but I at least see how to use this in a
typesafe way. Type safety doesn't have to mean static type checking --
it's enough for me that the programmer can write a program in which
knows the types that can go through are known.

> What I proposed about that is: when entering a function, the names
> used twice in the body of this function are copied into a distinct
> "transient" dict. When leaving the func this one dict is blanked.
> Names used from the main data dict are erased like the one from a
> normal stack. So, while the function is executed, names not found in
> the main stack+dict will be looked up inside the transient dict.

This gives a lexical scope to name use that it wouldn't otherwise have,
which is nice. It does mean that every call to every word must maintain
a dict of its own, which enormously increases the complexity of a
function call. It also means that deleting a use of a variable can have
potentially enormous effects on the global program (if the variable was
accessed twice, deleting one use will change the function to erase the
global name).

I think the problems with this are far worse than the benefits. It's not
a bad idea, but we/you need to work out a better way to indicate "this
deletes" versus "this does not delete".

I would suggest a simple syntactic token, akin to but opposite from
the :definition token you proposed. It would also make sense to place
that token in the dict effect comment/type signature.

A side effect of this is that you regain the ability to do everything
with a single global dict, rather than having to create a lexical dict
for every call to every function.

> Forth dictionaries, as I understand them, are kinds of modules like in
> eg Ruby: distinct namespaces.

No. Forth has only one dictionary. It's a data structure that consists
of names, code, and data linked together by at least one linked list.
The linked lists are called "vocabularies". The vocabularies, in turn,
are referenced by a "current vocabulary" variable, which provides the
starting point for all name lookups.

-Wm