[Push] Wondering about Code

[Erik Max Francis]

Lee Spector wrote:
> The CODE versions of DO and related instructions may or may not be strictly necessary in a world 
> with EXEC, but either way they may be useful for a variety of things. For example, you might want 
> to manipulate code in complicated ways and then execute it in the same program execution. In the 
> spec there EXEC doesn't haveall of the same code manipulation instructions as CODE does, but you 
> can manipulate on CODE and then use DO or DO* etc. to execute. Of course one could also just 
> implement more code manipulation instructions for EXEC. But even so, it can be handy to have more 
> than one stack for such things, so that the code you're manipulating doesn't get mixed up with 
> the code that you're executing except when you want it to.

Yes, I think for the system, having two separate stacks makes sense: 
One is what it executes and what is what it can separate "play with" to 
build things up.  Objects can be shuffle back and forth between them as 
desired.

> On orthogonality and engineering practices: On the one hand I do think it would be good to shore up 
> the Push spec and encourage standardization, but it seems that most of us who work on this stuff 
> (including me) are a little too eager to make new systems all of the time that add or subtract 
> things or make other changes. For example the last two systems I've made (schush and clojush) 
> deal with configuration in a totally different way from the spec and have omitted the NAME type 
> (just because I didn't think I'd need it and didn't have the time).

What did you use instead of it, arbitrary integers on a special stack? 
Or did you just not need the equivalent of ADFs for what you were doing?

> And instruction names are 
> changed a bunch in clojush because of Clojure/Java naming restrictions. Still, it'd be nice to 
> impose some order on all of this diversity, but I'm not sure how.

Some minimum spec and number of operators that should be supported to 
have a "real" Push system, perhaps?

> On orthogonality more specifically I think it's important to bear in mind that things that are 
> good practice for human engineering teams may not make as much sense for evolution. Might be the 
> opposite in some cases. That'd be an interesting research question to explore.

Yes, I strongly suspecting having access to multiple different (often 
very different) ways to accomplish the same thing is a big boon for a GP 
system.  This is often shunned in human-used languages (for various good 
reasons, though to various extents of overemphasis), but Push is not one 
of those.

I very strongly suspect that having a "full" set of overlapping, 
sometimes redundant operators that can accomplish things vs. a "minimum, 
elegant" set that humans might considering using would be a huge boon 
for GP evolution.  In fact, it's hard to see how it wouldn't be.  It 
wouldn't help with human readability with such programs, but then GP 
doesn't exactly cooperate in that area in the first place.

-- 
Erik Max Francis && max at alcyone.com && http://www.alcyone.com/max/
  San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
   There's this perfect girl / Living inside the shell
    -- Lamya