List Commands Library for 50g

[DavidM]

(07-14-2017 08:20 PM)Gilles59 Wrote:  Hi David,
I notice that, with DOPERM, on the contrary of DOLIST and DOSUBS, there is no possibilty to access to the stack in the inner program...

Code:


"Some stuff"
{ 1 2 3 4 }
2 
<< 
    HALT @ "Some stuff" is invisible here...
>>
DOPERM

I think it would be more powerfull to do as DOLIST and DOSUBS does.
This can avoid in many cases to create a variable where there no necessity to do.

This was actually intentional, and now that I'm checking on it I see that I was mistakenly assuming that I was mimicking the inherent behavior of the built-in commands by protecting the stack. This is clearly not the case. Where did I get the impression that the list commands worked this way? I'm not sure. Thanks for pointing this out!

The only consequence I can think of by not protecting the stack in this way is that it means that the user-supplied program should never delete any of the pre-existing stack elements. I've checked DOLIST/DOSUBS, and they apparently just notate the stack depth at the beginning of the command and assume that anything greater goes into the final result list. If the user-program deletes pre-existing stack objects, the grouped result doesn't include the same number of initial objects placed on the stack by the user program. In other words, if the user program deletes 3 pre-existing stack objects, then the first 3 objects in the result will be on the stack but not in the result list when DOLIST/DOSUBS completes. I could easily replicate that behavior with DOPERM and DOCOMB.

An example of what I'm referring to:

Code:

\<<
  1 2 3 4 5 6
  { a b c d e f g }
  1
  \<<
    IF NSUB 1 == THEN NIP NIP NIP END
  \>>
  DOSUBS
\>>