[Push] Top Level Code or Exec?

Tue Apr 20 09:30:09 EDT 2010

I forgot to answer about DEFINE -- yes, I think that it should indeed pop both stacks (the stack of the type it is defining, e.g. the FLOAT stack for FLOAT.DEFINE, and the NAME stack). That just follows the general convention that all arguments to all instructions are popped unless there's an explicit note to the contrary.

Just by inspection, looking at the code for the float power example, I'm not immediately sure if another ARG is needed or not but I think you may be right. I can see that without another ARG (or without a dup or something like that) the first call to FLOAT.* will be a no-op if there was nothing else previously on the FLOAT stack, which would produce an off-by-one error on the exponent (unless I'm not thinking through the loop bounds correctly). When I wrote that example I'm sure that I tested it manually (and alas informally) but maybe I didn't notice an off-by-one error. I can't try this trivially at the moment because I'm only set up to run my Clojure implementation, which implements all of Push3 EXECPT NAMEs.

 -Lee

On Apr 20, 2010, at 1:43 AM, Rud Merriam wrote:

> Thanks, Lee & Maarten,
> 
> The confusion goes back to my original email last week. I was assuming that
> CODE.DO and CODE.DO* executed the code on their stack directly since the
> documentation did not say they should move the list to the EXEC stack. The
> documentation for DO*RANGE & DO*TIMES said this explicitly so I assumed with
> the others not saying it they didn't move the list. 
> 
> Got the 'float power' example in the documentation working tonight which I
> think is complicated enough that the interpreter is working well. I did get
> hung up a bit on the example until I realized it needed an ARG after the
> FLOAT.DEFINE to put the starting value back on the stack. (I implemented
> DEFINE to pop the value from the stack when it is being defined. Is that
> wrong?)
> 
> Thought maybe you'd be interested to know that I setup unit tests using a
> C++ framework called TUT. There is a unit test for each instruction that
> I've implemented, plus list manipulation routines. The unit test checks the
> key points like the values on the stacks and stack depths. Unit testing was
> just coming into popularity as I was winding down my employment period (I am
> now retired). After I got the example working I ran all the unit tests and
> all but one worked and it just needed parens around the input list. 
> 
> Now onto genetic operators...
> 
> 
> - 73 - 
> Rud Merriam K5RUD 
> http://mysticlakesoftware.com/
> 
> 
>> -----Original Message-----
>> From: Lee Spector [mailto:lspector at hampshire.edu] 
>> Sent: Monday, April 19, 2010 8:29 PM
>> To: Maarten Keijzer
>> Cc: push at lists.hampshire.edu; Rud Merriam
>> Subject: Re: [Push] Top Level Code or Exec?
>> 
>> 
>> 
>> Same deal in the other implementations that I know about, 
>> although not implemented with CODE.DO* (although that is 
>> indeed elegant). 
>> 
>> It has to go on to the EXEC stack to be executed, and putting 
>> it on the CODE stack is handy for programs that manipulate 
>> their own code. In several implementations the push onto the 
>> CODE stack (and the post-run popping of the CODE stack, which 
>> in Maarten's implementation will also be accomplished by 
>> CODE.DO*) can be turned on or off with a parameter.
>> 
>> -Lee
>> 
>> On Apr 19, 2010, at 4:01 PM, Maarten Keijzer wrote:
>> 
>>> 
>>> We wanted to have the program code on the code stack for 
>> the program 
>>> to
>>> manipulate. Although code on the exec stack could in 
>> principle copy itself on 
>>> the code stack (with some trouble), we thought it would be 
>> easiest to push the 
>>> code to be executed both on the code stack AND on the exec stack.
>>> 
>>> So that's what we do. In the C++ version, this is called the push 
>>> calling
>>> convention, and it is implemented by pushing code on the 
>> CODE stack, and 
>>> pushing the CODE.DO* instruction on the exec stack.
>>> 
>>> hth,
>>> 
>>> -Maarten-
>>> 
>>> 
>>> On Monday 19 April 2010 09:46:21 pm Rud Merriam wrote:
>>>> The documentation on Push3 is a bit confusing as to where 
>> to load a 
>>>> program.
>>>> 
>>>> In discussing configuration and later in the Factorial example the 
>>>> implication is that a program is read from a file and then pushed 
>>>> onto the CODE stack.
>>>> 
>>>> But the description of the execution environment - where 
>> the CODE and 
>>>> EXEC execution is contrasted - seems to imply a program is pushed 
>>>> onto the EXEC stack. This is in the Push Concepts section.
>>>> 
>>>> I'm guessing the pushing to CODE is the approach used, although it 
>>>> seems inconsistent with the switch to EXEC in Push3.
>>>> 
>>>> 
>>>> - 73 -
>>>> Rud Merriam K5RUD 
>>>> http://mysticlakesoftware.com/
>>>> 
>>>> 
>>> _______________________________________________
>>> Push mailing list
>>> Push at lists.hampshire.edu 
>>> https://lists.hampshire.edu/mailman/listinfo/push
>> 
>> --
>> Lee Spector, Professor of Computer Science
>> School of Cognitive Science, Hampshire College
>> 893 West Street, Amherst, MA 01002-3359
>> lspector at hampshire.edu, http://hampshire.edu/lspector/
>> Phone: 413-559-5352, Fax: 413-559-5438
>> 
>> Check out Genetic Programming and Evolvable Machines: 
>> http://www.springer.com/10710 - http://gpemjournal.blogspot.com/
>> 
>> _______________________________________________
>> Push mailing list
>> Push at lists.hampshire.edu 
>> https://lists.hampshire.edu/mailman/listinfo/push
>> 
> 
> _______________________________________________
> Push mailing list
> Push at lists.hampshire.edu
> https://lists.hampshire.edu/mailman/listinfo/push

--
Lee Spector, Professor of Computer Science
School of Cognitive Science, Hampshire College
893 West Street, Amherst, MA 01002-3359
lspector at hampshire.edu, http://hampshire.edu/lspector/
Phone: 413-559-5352, Fax: 413-559-5438

Check out Genetic Programming and Evolvable Machines:
http://www.springer.com/10710 - http://gpemjournal.blogspot.com/