On Sun, 30 Dec 2007 15:14:48 -0500 "Daniel Ehrenberg" <[EMAIL PROTECTED]> wrote:
> > 2) Words that operate on data types leave (especially as "transforms") > > them on the stack or a transformed version. That's tuples, vectors, > > hashes, etc. and words like push, >string, etc. Words like at also fit > > this way by transforming their inputs to a single output. > > 3) Alternative words for rule #2 that don't leave them on the stack end > > in !. This would be used in the least common cases and would be a way > > to say "watch out!". > > Words do follow a consistent convention for stack effects right now; > it just isn't this one that you've specified. The difference is in > parts 2 and 3 of what you wrote. The convention is that words > generally don't return their arguments; they return other things. So > >string returns the new string, but push doesn't return the same > sequence that was pushed to. However, that's not a very clear rule I can follow since add does what push does but leaves things on the stack. Choose one or the other and make a succinct rule I can follow so it's less cognitive burden to work in the language. I believe the actual rule is this: 2) "Transform words always eat their parameters, and either leave a new _different_ thing on the stack, OR modify the original thing in place NOT leaving anything on the stack." It's the last part after OR that creates the inconsistency and annoyance for no explained advantage other than "that's just how it is". As a programmer it tends to not matter how things are, so long as they are explained clearly and I get a decent reason that doesn't make me scream "bullshit". If the rule's #2 then that's the rule, but I haven't seen any "standard stack protocol design guide" yet. That's more what I'm saying, not that things should work how I described them. > Of course, just because this is the current convention doesn't mean > it's the way things should be. Maybe we should adopt something like > this, as long as we are consistent, at least within the core > libraries. (As Chris rightly pointed out, it makes sense to experiment > in other libraries.) Or, provide some convenience words for people so they don't need to do over all the time. Just these two words would be a good start: : << over push ; : >> dup pop ; And if that's bad form, then a legit reason with a good motivation would make it easier to start using the others exclusively. > On #concatenative, you (Zed) suggested that nth should act like over > nth, but in my experience things like that (at least in the general > case, and with nth) are not useful. Very often (I suspect most of the > time, but I haven't counted) you don't end up needing to preserve the > sequence itself in that way. One convention in argument ordering is > that we try to take the argument most likely to be literal from the > top of the stack, which is why nth, set-nth, at and set-at take their > sequence/assoc from the top of the stack. Well, that's also my total newbie status with the language (still). Keep in mind that I'm now saying that I don't care which way it is, just give me something to hang my intellectual hat on so I don't have to constantly look up every word for stack effect. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
