[Push] Re: push [possibly without type stack/mechanisms]

[Lee Spector]

[Chris, I'm ccing this to the Push list...]

In response to Chris's message (below) I've been mulling what it would mean
to completely remove the type stack & related mechanisms from a version of
Push. I have some thoughts that I'll jot down in no particular order -- I
haven't really organized my thoughts yet... all responses welcome:

- I know that in at least one non-Hampshire Push implementation the type
stack was abandoned (Russ's? based on an argument about evolvability?), but
I don't know what the verdict was.... anyone have experience with this to
report?

- The primary use for the TYPE type (the type stack and type literals) in
Push is to disambiguate overloaded instructions, and it's not clear to me
how important the overloading is, if at all, FOR PROGRAM EVOLUTION. A
possibly independent question is its importance FOR DEVELOPMENT/MAINTENANCE
of the Push language core/versions.

- The TYPE type leads to some elegances, I think, but it is also the source
of considerable ad-hoc-ishness, like the necessity for the type stack
bottom and the way that the type stack generally grows without bound.

- I'm curious what other types people have added and if the TYPE type
played any new important role in any of the added stuff. I've been using
VECTOR (three-tuples) and a simple form of UNITARY-MATRIX (for quantum
computing) in addition to the types in the GPEM paper. (Actually I've been
using a subset of the GPEM types/instructions in many cases...) I know
others have also used DATA (another expression type). The TYPE stack has
played no special role in the way we've been using VECTOR and
UNITARY-MATRIX (e.g. we've had special instructions like V+).

- Eliminating the TYPE type (and thereby the type/instruction hierarchy)
will increase the size of the instruction set  A LOT, which I would
normally assume would decrease evolvability due to combinatoric explosion
of random programs. But this is really complicated. For example, in the
current Push you might argue that most code is generally fragile with
respect to mutations (etc.) that disrupt type literals, and that code
useful in the context of one type is rarely useful in the context of
another type. I could imagine cases were utility would cross type
boundaries (e.g. for int/float, code/child), but it's hard to know what the
overall effect would be. Maybe there'd be an effect with respect to
population sized, like we'll have to use larger populations/program sizes
early in evolution to get all of the relevant instructions into the mix?

- It'd be good to have a uniform scheme for integrating type names into
instructions, like integer.+, vector.+ or something. Does the "." seem
good? I wonder if it's also time to think more systematically about how
literals are represented in code. We've made up conventions for vectors,
etc., but I wonder if there should be something more explicit or uniform...
Maybe not. This is in the same category as my wish to have some explicit
way to describe the language subset being used...

- The type type/hierarchy had a software engineering benefit to the
language implementor, even if the benefit to evolvability is unclear (or
negative): for example, to add a new expression type is a one-liner in my
implementation. Without type literals we'll have to copy and rename all of
the expression instruction definitions... right? I guess this depends on
implementation decisions. But it would definitely be nice to retain the
ease of adding new types that share functionality. One thought is to retain
the hierarchy-based interface for defining types but then compile the types
away, producing instructions with names TYPE.NAME for every implemented
TYPE/NAME pair.

- CONVERT will go away, to be replaced by whatever TYPE->TYPE instructions
make sense.

 -Lee



At 11:06 PM -0400 4/13/03, Chris Perry wrote:
>I'm off and running with a version of Push that has a customizable
>interpreter state. I've sacrificed the type hierarchy to do this. Based on
>our brief conversations it doesn't seem to be a big price to pay (the push
>programs have a bigger set of instructions but the code is easier to read).
>
>My goal with this effort is to cobble together a minimal set of types and
>instructions for doing the RenderMan stuff we've discussed, while
>simultaneously permitting smoother callback-like behavior so we can all use
>the same library again.
>
>Now if the type hierarchy is dead, does that have ramifications for the type
>stack? I can see instructions like convert still needing a type stack, but
>do we need a type stack bottom anymore? If an "I+" (integer plus)
>instruction is detected, after all, it goes straight to the integer stack.
>
>Any thoughts?
>
>- chris

--
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