Re: [stack] unary functions from X to Y?

in XY, X is the stack and Y is the queue, but X and Y will contain
references to the environment (name-value bindings) which can be
altered with ; ... ; definitions.  i think i started work on what
i was calling XYZ, in which functions were maps from X, Y, and an
environment Z, a map from symbols to values.  my plan was to get
rid of ; definitions, and use <~ and ~> to move items between the stack
and the environment.  i still think this is a good idea, at least
for reasons of theoretical purity.  either that or eliminate run-
time changes to the environment, so that the meaning of a name is
eternal.

----- Original Message ----- 
From: "William Tanksley" <[email protected]>
To: <[email protected]>
Sent: Sunday, March 08, 2009 11:58 AM
Subject: Re: [stack] unary functions from X to Y?


> John Nowak wrote:
>> In my email prior to this one, I suggested that the definition of  
>> concatenative languages should be limited such that all functions are  
>> unary functions from some aggregate X to some aggregate Y where X and  
>> Y are both the same "type" (e.g. a stack or a stack/queue tuple). This  
>> definition covers all existing concatenative languages. More  
>> importantly however, it rules out languages like FP where functions  
>> can do things like take a list and return a number.
>> My first question then is if anyone agrees that this is a useful  
>> restriction.
> 
> I agree.
> 
>> Should we agree it's useful, the next thing I'd want to try is to  
>> determine an aggregate type that would be valid for all existing  
>> concatenative languages. To start, all existing concatenative  
>> languages include a stack. Some include more than a stack however, so  
>> our aggregate type must be a tuple of a stack and something else.
> 
> I think all of them use more than a stack.
> 
>> XY offers a queue representing the future of a computation, but really  
>> all concatenative languages can be viewed in terms of having such a  
>> queue; some languages simply don't make it programmer-accessible. I  
>> think it therefore reasonable to add a queue to our tuple.
> 
> Actually, a queue is a bad choice for the future structure. XY uses it
> because it wanted an easy to do 'dip', but 'dip' doesn't require a
> persistent structure. When used only to view and modify the future, XY
> treats its queue as a stack -- which is the correct approach.
> 
>> Factor offers a retain stack (the direct use of which is nearly  
>> eliminated at this point I think). We do not need to add this to our  
>> tuple however because we can simply view it as being passed around on  
>> the top of the stack. After all, the retain stack can only represent  
>> the "past" in terms of the current computation, so it makes sense to  
>> group it in with the "main" stack which holds the sum of past  
>> computation.
> 
> Yes, the retain stack is part of the past (quite apart from it being
> obsolete!) -- although I wouldn't want to model it as being "on" the
> main stack.
> 
>> Forth offers a return stack. It may be possible to formulate this as  
>> part of the queue, but it's not clear to me exactly how this would  
>> work. I wonder if it may be cleaner to add the return stack to our  
>> tuple. In this scenario, the "main" stack is the past of the  
>> computation, the queue is the future, and the return stack is the  
>> "present" of the computation. The utility of separating the "present"  
>> from the "future" is that Forth can manipulate the present using r>  
>> and >r. It cannot, as far as I know, manipulate the "future" in any way.
> 
> I don't understand what you're saying at all. The XY queue is
> essentially a high-resolution return stack. Forth's return stack plus
> its instruction pointer is similar to the queue -- it tells you what's
> going to happen in the future.
> 
> I could understand you classifying the IP as being the 'present', in
> which case XY's queue melds the present with the future -- but I don't
> see much use in that, since really everything in the XY queue and
> everything after the Forth IP is in the future.
> 
> XY lets you manipulate the future at a finer grain than Forth does.
> 
>> could then classify concatenative languages by which elements of that  
>> tuple are made user-accessible: Joy would make only the past  
>> accessible, Forth would make the past and present accessible, and XY  
>> would make the past and future accessible.
> 
> The first question I think is appropriate would be not which parts are
> open to programmer manipulation, but rather what the effects of
> manipulations are. Appending stuff to XY's queue behaves very
> differently from pushing stuff onto it.
> 
>> This is just a very rough idea. Any thoughts would be much  
>> appreciated. Specifically, I am unsure if separating the "present" and  
>> the "future" is a valid approach. I do not, however, have a way of  
>> removing the need for the "present" in the case of Forth at the  
>> moment; viewing the return stack as part of the queue seems  
>> inappropriate. More precisely, it would mean that only part of the  
>> queue would be user-accessible. Having to deal with "parts" would make  
>> the classification system less useful. Perhaps Forth's return stack  
>> access is a unique property we can avoid dealing with and could  
>> therefore reclassify Forth as a "mostly concatenative" language or  
>> somehow "pre-concatenative". Then again, perhaps not, and we'd have to  
>> find a way of dealing with it.
> 
> Forth is hardly the only language to use an IP and a return stack -- it
> seems odd to make a classification of languages that share the common
> feature of being extremely resource-hungry to implement. It's probably
> not a good idea to make the lynchpin of a classification system an
> experimental feature of a single language.
> 
> With that said, though, I also disagree that having to deal with "parts"
> is a problem. This is ALL experimental; we don't know the right way of
> looking at the problem. I think Forth's system is terrible, since it
> negates the benefits of easy factoring; but XY's system makes it hard to
> look as far into the future as Forth's system can. But what about
> partial continuations -- neither language provides those, although both
> come close.
> 
>> - John
> 
> -Wm
> 
> 
>