[Push] Typing Stack Information

Lee Spector lspector at hampshire.edu
Wed Oct 29 14:28:31 EST 2003


Rud,

The idea you outlined sounds much like the TYPE stack mechanism in the
original version of Push -- the TYPE stack is consulted (but not popped)
for each instruction executed to determine which method to execute (since
many instructions are overloaded). But perhaps I didn't understand your
proposal correctly...

In Push2, as you note, we're dropping this idea and the whole concept of
instruction overloading. You ask a good question about the possible impacts
of doing this (e.g. on evolution of modularity), but we haven't done
sufficient comparisons to be able to say anything definitive on this front.
We dropped the TYPE stack mechanism because we felt it added complexity
without contributing much to features of the language that are clearly
useful, e.g. the easy handling of multiple types, automatic evolution of
program architecture and control structures, support for autoconstructive
evolution (programs that produce their own offspring along with other
results), etc. The overloading mechanism seemed cute and consonant with OOP
ideas, and we could IMAGINE ways in which it might help evolutionary
processes, but it did indeed add complexity and the benefits were unclear.
Since we wanted the new version of Push to be "lean and mean" in some
senses -- easy to explain, easy to configure, easy to extend, etc -- we
opted to drop the TYPE stack mechanism.

Push2 should be ready "real soon now" and we'll simultaneously post C++ and
Lisp versions...

 -Lee



At 12:47 AM -0600 10/29/03, Rud Merriam wrote:
>I just started looking at Push in the last few days. Also fairly new to
>looking at evolution of programs.
>
>I see from a recent email in the archives that Push2 is under development
>and it omits the TYPE stack. Instead all operators will have type prefixes.
>
>I ask for comments on the idea of having a single stack that contains type
>information for each entry. The interpreter would examine the type data to
>determine the overloaded operator to execute. Would this make program
>evolution more or less difficult? Might it encourage modularity since it may
>be easier to do all integer stack operations at one time and all code stack
>operations at another.
>
>I'm starting on a C++ implementation. I did see an earlier message about
>Push2 that outlined ideas so I'll use it as the guide for my first pass.
>I'll catch up with the final specifications when it is available.
>
>Rud Merriam
>K5RUD
>
>
>
>_______________________________________________
>Push mailing list
>Push at lists.hampshire.edu
>http://lists.hampshire.edu/mailman/listinfo/push

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




More information about the Push mailing list