Re: Fwd: [stack] Concatenative Research

--- In [email protected], John Carter <john.carter@...> wrote:
>
> On Mon, Jan 31, 2011 at 1:20 PM, Justin <zallambo@...> wrote:
> 
> > Hello. Is this forum still alive? I haven't shown my head here for a couple
> > of years. I'm a MA/CS major with an ongoing interest in giving concatenative
> > languages a firmer mathematical foundation. I have a few partial results:
> > (i) an operational semantics, (ii) a concept of & application for
> > homomorphisms, (iii) a type system. Is anyone else around here interested in
> > this sort of research? Here's a link to my (ongoing) work,
> >
> > http://dl.dropbox.com/u/17328602/concat/index.html
> >
> >
> 
> What may be interesting and useful would be to return to typed variables
> (named values variety) and something like a SQL "natural join".

I don't know what you mean. Could you give an example? (I don't have a good mental model of databases.)
 
> 99% of the time which function result variable, needs to be bound which
> input variable, is obvious and can be automatically inferred from their type
> and name.
>
> By making the rules for doing this explicit, you should be able to create a
> concatenative language that doesn't involve the notion of a stack, nor are
> the program fragments cluttered with irrelavent variable name references or
> stack manipulation "fluff".
> 
> I would argue that any language where the function definitions are cluttered
> with stack manipulations OR variable references has NOT yet met the full
> promise of concatenative languages.

I am aware of three methods of passing data around:
1. stack manipulation
2. variable references (the stateful kind)
3. implicit state (think of the flags register in assembly)

We can probably agree that (3) is usually a bad idea. Are there other methods? What else could a concatenative language do?